泥潭日报 uscardforum · 每日精选

胡渊鸣 | 我给 10 个 Claude Code 打工

内容摘要

帖子标题 胡渊鸣 | 我给 10 个 Claude Code 打工

帖子ID

483890

============================================================================== [旧摘要 - 已被纳入的内容] ============================================================================== 胡渊鸣 | 我给 10 个 Claude Code 打工

AI 编程工具 Claude Code 引发热议,用户分享使用经验,讨论效率提升、自动化流程、集成方式、代码质量及未来发展。定制化工具、官方 Bot 集成、多模态交互成为焦点,同时对 AI 生产力、工作模式转变及语言发展趋势展开深入探讨。

1. 关键信息

  • (之前已归纳) 作者胡渊鸣分享了使用 10 个 Claude Code 辅助编程的经验。
  • (之前已归纳) 用户 ctzsm 表示信任胡渊鸣的分享。
  • (之前已归纳) 用户 cnxcnx 认为 AI 辅助编程转变迅速,研究者可快速适应,产出与 token 成正比,本人近半年代码 100% AI 生成,但仍在适应多线程。
  • (之前已归纳) 用户 tty17 认为 AI 取代程序员速度超预期,预测两年内可能取代 50% 程序员。
  • (之前已归纳) 用户 qwaszx 表示仅在 Chrome Jupyter Notebook 中编写代码,不习惯 VS Code 查看。
  • (之前已归纳) 用户 misc 提到工作环境权限限制导致申请耗时低效。
  • (之前已归纳) 用户 xxxyyy 强调高度定制化工具的重要性,但认为不适合规模化部署。
  • (之前已归纳) 用户 xxxyyy 认为工具规模化部署会带来维护和培训问题,可能回归原点。
  • (之前已归纳) 用户 收束观测者 认为 AI Agent 时代,大佬可直接要求“自己 fork 维护”,搞不定则换人。
  • (之前已归纳) 用户 收束观测者 区分 QoL 工具(可定制)与 gatekeeper 工具(不可定制)。
  • (之前已归纳) 用户 xxxyyy 担忧内部流程或资源格式改变导致工具更新灾难,占用大量时间。
  • (之前已归纳) 用户 收束观测者 认为,若 Agent 修改,低人力成本即可接受。
  • (之前已归纳) 用户 xxxyyy 认为 Agent 正确率不足,强行使用会复杂化简单问题。
  • (之前已归纳) 用户 Tesla 认为这是人指挥机器干活到机器指挥人 review 代码的历史进程。
  • (之前已归纳) 用户 收束观测者 将此进程比作三班倒,认为人的时间需服从机器。
  • (之前已归纳) 用户 孙宇晨 将 Agent 方法论类比管理岗,管理听话懂事的 Agent。
  • (之前已归纳) 用户 uplus5f7b 认为 Agent 磨洋工且擅长看人下菜碟,难管理。
  • (之前已归纳) 用户 孙宇晨 认为 Agent 可迭代更快,取决于管理者政策,不像真人可怪罪下属。
  • (之前已归纳) 用户 桂花粥 询问研究代码相关 AI 工具。
  • (之前已归纳) 用户 vwai 提到自己不会多线程,可能需购买 Claude Code。
  • (之前已归纳) 用户 Tony96 引用 PingCAP CTO Dongxu 观点,提出“Ralph loop”,认为未来基础设施需适应 Agent 的多并发、短周期、个性化需求,代码产出成本转为 token。
  • (之前已归纳) 用户 jzcracker 分享复刻的 Claude Code 界面,效率达 1000x。
  • (之前已归纳) 用户 马蹄快跑 询问是否为手搓的 Claude Manager。
  • (之前已归纳) 用户 jzcracker 回答是 Claude 帮忙搓的。
  • (之前已归纳) 用户 marszoom 认为 Agent Coding 范式是迭代快、成本低,但面向终端产品难以完全不 review,存在 bug。
  • (之前已归纳) 用户 ctzsm 建议多人协作使用 centralized AI agent 共享 context。
  • (之前已归纳) 用户 xxxyyy 认为当前方式仅适合 toy project,生产环境需 review。
  • (之前已归纳) 用户 marszoom 同意公司代码不能随意看。
  • (之前已归纳) 用户 马蹄快跑 询问是否将 skill check in to codebase 统一组内解决问题。
  • (之前已归纳) 用户 misc 再次强调工作环境权限限制问题,需手动确认。
  • (之前已归纳) 用户 marszoom 认为需创造 Agent friendly 环境,read only 权限应 disable。
  • (之前已归纳) 用户 zzfdafw 认为大佬 productivity 10x 创造价值,普通码农 3x 5x 只能卷同事。
  • (之前已归纳) 用户 KCNA 认为工程师地位不如 Claude Code。
  • (之前已归纳) 用户 devilevga 认为胡渊鸣长相像疫情期间火的 tech lead。
  • (之前已归纳) 用户 收束观测者 分享 Agent 完全接入 Staging 环境经验,生产力“炸裂”。
  • 新增:用户 jzcracker 分享复刻的 Claude Code 界面完全可用,支持发图发语音,无需手动授权,并提出“idea is no longer cheap, idea is gold now”的观点。
  • 新增:用户 吃货不吐葡萄皮 建议 AI 辅助生成 Jupyter Notebook。
  • 新增:用户 收束观测者 询问 Claude Code 前端生成 Prompt 的小模型是否可选,并遇到 MCP 不被调用问题,暗示 Agent 理解调用现有工具可能存在障碍。
  • 新增:用户 郁小南 建议通过监听 Slack WebSocket 调用 Claude,结束后通过 Hook 回复 Slack,实现流畅 Agent 交互。
  • 新增:用户 258 提到 Claude Code 已支持添加 Telegram/Slack Bot,认为官方升级爽快,并疑问网页版 Claude 是否能访问本地代码和数据。
  • 新增:用户 郁小南 确认 Slack Bot 集成方式,并类比 OpenCLAW QMD 升级,强调官方集成好处。
  • 新增:用户 pqsj 对作者背景(清华姚班、MIT 博士、创立公司)提出“婚绿”疑问,引发移民身份讨论。
  • 新增:用户 258 回应移民身份讨论,提到 EB1A 签证快速处理。
  • 新增:用户 Wi-Fi 认为 Chat 模式非理想交互,建议直接接入看板 UI(如 Trello),让 AI 直接读取。
  • 新增:用户 258 提出自然语言可能非 Agent 最佳沟通方式,为性能可能退化为难以解释的 Token。
  • 新增:用户 大沙雕 认为 AI 时代最难替代的是“沙滩和海风”等服务性工作,但也担忧 AI 导致失业减少享受服务人群。
  • 新增:用户 收束观测者 预测 C++ 可能消亡,Rust 将迎来春天,因面向编译器编程缺点在 AI 时代不再重要。
  • 新增:用户 郁小南 表示,安装 Claude Code 很简单。
  • 新增:用户 收束观测者 认为 AI 带来了创造力爆发和思如泉涌的体验,每天冒出新主意增加烧 token 的数量级,并表示未来找工作时会将“token 让我无限烧”作为第一条要求。
  • 新增:用户 noRainNoShine 感觉用大模型写代码有玩游戏的感觉,反馈快,有成就感,认为未来产业可能类似游戏行业,头部付费玩家付费极高,并非为了生产力而是为了快乐。
  • 新增:用户 两只老虎 认为当前 AI 生成代码效果不太行,需要让 AI 自己修复 bug。
  • 新增:用户 吃货不吐葡萄皮 提出,如果全部让 AI 手搓,有时会有格式错误,建议使用 nbformat package 将代码写好并转成 Jupyter,再用 papermill 运行。
  • 新增:用户 Wi-Fi 推荐尝试 moonshotai/Kimi-K2.5 模型,并建议使用 vllm 快速部署。
  • 新增:H2TG 提出,在“如何看待”的帖子中,不相关的回复属于答非所问,并认为此类帖子应零回复。
  • 新增:awaken01641 强调论坛内容总结应简短精炼,并对“如何看待”类帖子的回复提出规范要求。

2. 羊毛/优惠信息

3. 最新动态

  • (之前已归纳) Claude Code 已支持直接添加 Telegram/Slack Bot,官方集成能力增强。
  • 新增:Claude Code 的复刻界面已完全可用,支持发图发语音,无需手动授权。
  • 新增:用户 Wi-Fi 推荐尝试 Kimi-K2.5 模型,并使用 vllm 快速部署。

4. 争议或不同意见

  • (之前已归纳) 用户 qwaszx 对 AI 编程工具在特定环境(Chrome Jupyter Notebook)的适用性存疑。
  • (之前已归纳) 用户 xxxyyy 对“大佬自研工具可裁团队”观点存疑,认为规模化部署和维护问题重重。
  • (之前已归纳) 用户 xxxyyy 对 AI Agent 完全替代人工 review 存疑,认为生产环境仍需 review。
  • (之前已归纳) 用户 zzfdafw 认为 AI 生产力提升对不同层级员工意义不同。
  • (之前已归纳) 用户 richardfatman 担忧 Agent 迭代产物质量。
  • 新增:用户 收束观测者 遇到 Claude Code 调用 MCP 问题,暗示 Agent 在理解和调用外部工具时可能存在不足。
  • 新增:用户 郁小南 和 258 讨论 Agent 交互方式,从 WebSocket 监听至 Bot 集成,并质疑自然语言沟通效率。
  • 新增:用户 Wi-Fi 提出 Chat 模式局限性,建议结构化任务管理界面。
  • 新增:用户 pqsj 对作者背景提出移民身份疑问,引发个人经历身份讨论。
  • 新增:用户 大沙雕 认为服务性工作(如海滩和海风)难替代,但担忧 AI 导致失业。
  • 新增:用户 收束观测者 预测 C++ 衰落,Rust 发展,因 AI 降低对编程技巧依赖。
  • 新增:用户 两只老虎 认为当前 AI 生成代码质量仍需提高,需要 AI 自我修复 bug。
  • 新增:H2TG 认为“如何看待”类帖子不应有回复,否则属于答非所问。
  • 新增:awaken01641 强调论坛内容总结应简短精炼,并对“如何看待”类帖子的回复提出规范要求。

5. 行动建议

  • (之前已归纳) 密切关注 AI 在编程领域的快速发展,考虑应用于自身工作。
  • (之前已归纳) 关注 AI 编程工具对特定开发环境(如 Jupyter Notebook)的支持。
  • (之前已归纳) 尝试使用 Claude Code 等 AI 编程工具,探索全脱手流程。
  • (之前已归纳) 关注 AI Agent 在软件开发中的应用模式及基础设施适应性。
  • (之前已归纳) 在实际生产环境中,对 AI 生成代码需审慎 review。
  • (之前已归纳) 团队协作可考虑使用 centralized AI agent 共享 context。
  • (之前已归纳) 考虑将常用 AI 功能封装成 skills,check in to codebase 统一使用。
  • (之前已归纳) 关注并反馈工作环境权限限制问题,推动 Agent friendly 环境。
  • (之前已归纳) 关注 Agent 完全接入生产环境的产物质量。
  • (之前已归纳) 积极探索和创造 Agent friendly 工作环境。
  • 新增:用户 jzcracker 的经验表明,定制化工具可实现 AI 编程无缝集成,无需手动授权,强调“想法的价值”。
  • 新增:对于使用 Jupyter Notebook 的用户,可尝试 AI 辅助生成 Notebook,并利用 nbformat 和 papermill 等工具进行格式化和运行。
  • 新增:对于 Agent 集成,可利用官方 Slack/Telegram Bot,或自行开发服务监听 WebSocket。
  • 新增:评估 Agent 效率时,注意其理解调用工具的不足,探索更优交互模式(如直接接入看板 UI)。
  • 新增:关注 Agent 是否会超越自然语言,发展更高效沟通方式。
  • 新增:思考 AI 时代下人类工作的本质和价值,以及哪些领域(如体验式服务)更具韧性。
  • 新增:关注 Rust 等新语言在 AI 辅助编程背景下的发展潜力。
  • 新增:用户 郁小南表示,安装 Claude Code 很简单,可按需尝试。
  • 新增:体验 AI 编程带来的乐趣和创造力爆发,将其视为一种类似游戏的体验,并考虑未来工作中的“无限烧 token”需求。
  • 新增:关注 AI 生成代码的质量,并探索让 AI 自我修复 bug 的方法。
  • 新增:尝试使用 moonshotai/Kimi-K2.5 模型,并结合 vllm 快速部署,以提升模型运行效率。
  • 新增:关注 AI 编程工具的集成方式,如通过 Slack/Telegram Bot 或 WebSocket 监听,并尝试定制化界面以提高效率。
  • 新增:理解论坛讨论的规范,避免答非所问,并对内容总结的精炼性提出要求。

============================================================================== [新增回复内容] ==============================================================================

新增回复数

2

================================================================================

================================================================================ --- 第 116 楼来自 H2TG 的回复 (2026-02-23 15:22:09 PST) --- 所以,那些题问的是“我”的意见,还是“第三方公允的评价”?

================================================================================ --- 第 117 楼来自 无名之辈 的回复 (2026-03-12 19:38:33 PDT) --- AI大炼钢铁了2周回来看 这篇文章能看懂一点了

================================================================================

AI 编程工具 Claude Code 引发热议,用户就“如何看待”类帖子的提问方式及论坛内容总结的性质展开讨论,并有用户表示经过一段时间的 AI 实践后,对原文的理解有所加深。

1. 关键信息

  • (之前已归纳) 作者胡渊鸣分享了使用 10 个 Claude Code 辅助编程的经验。
  • (之前已归纳) 用户 cnxcnx 认为 AI 辅助编程转变迅速,本人近半年代码 100% AI 生成,但仍在适应多线程。
  • (之前已归纳) 用户 tty17 预测 AI 可能在两年内取代 50% 程序员。
  • (之前已归纳) 用户 qwaszx 不习惯 VS Code 查看代码。
  • (之前已归纳) 用户 misc 提到工作环境权限限制导致申请耗时低效。
  • (之前已归纳) 用户 xxxyyy 认为高度定制化工具不适合规模化部署,规模化部署会带来维护和培训问题。
  • (之前已归纳) 用户 xxxyyy 认为 Agent 正确率不足,强行使用会复杂化简单问题。
  • (之前已归纳) 用户 Tesla 认为这是人指挥机器干活到机器指挥人 review 代码的历史进程。
  • (之前已归纳) 用户 收束观测者 将此进程比作三班倒,认为人的时间需服从机器。
  • (之前已归纳) 用户 孙宇晨 将 Agent 方法论类比管理岗,管理听话懂事的 Agent。
  • (之前已归纳) 用户 uplus5f7b 认为 Agent 磨洋工且难管理。
  • (之前已归纳) 用户 孙宇晨 认为 Agent 可迭代更快,取决于管理者政策。
  • (之前已归纳) 用户 vwai 提到自己可能需购买 Claude Code。
  • (之前已归纳) 用户 Tony96 引用 PingCAP CTO Dongxu 观点,提出“Ralph loop”,认为未来基础设施需适应 Agent 的多并发、短周期、个性化需求,代码产出成本转为 token。
  • (之前已归纳) 用户 jzcracker 分享复刻的 Claude Code 界面,效率达 1000x,并提出“idea is no longer cheap, idea is gold now”的观点。
  • (之前已归纳) 用户 marszoom 认为 Agent Coding 范式是迭代快、成本低,但面向终端产品难以完全不 review,存在 bug。
  • (之前已归纳) 用户 ctzsm 建议多人协作使用 centralized AI agent 共享 context。
  • (之前已归纳) 用户 xxxyyy 认为当前方式仅适合 toy project,生产环境需 review。
  • (之前已归纳) 用户 marszoom 认为需创造 Agent friendly 环境,read only 权限应 disable。
  • (之前已归纳) 用户 zzfdafw 认为大佬 productivity 10x 创造价值,普通码农 3x 5x 只能卷同事。
  • (之前已归纳) 用户 KCNA 认为工程师地位不如 Claude Code。
  • (之前已归纳) 用户 收束观测者 分享 Agent 完全接入 Staging 环境经验,生产力“炸裂”。
  • (之前已归纳) 用户 吃货不吐葡萄皮 建议 AI 辅助生成 Jupyter Notebook。
  • (之前已归纳) 用户 收束观测者 询问 Claude Code 前端生成 Prompt 的小模型是否可选,并遇到 MCP 不被调用问题,暗示 Agent 理解调用现有工具可能存在障碍。
  • (之前已归纳) 用户 郁小南 建议通过监听 Slack WebSocket 调用 Claude,结束后通过 Hook 回复 Slack,实现流畅 Agent 交互。
  • (之前已归纳) 用户 258 提到 Claude Code 已支持添加 Telegram/Slack Bot,认为官方升级爽快,并疑问网页版 Claude 是否能访问本地代码和数据。
  • (之前已归纳) 用户 郁小南 确认 Slack Bot 集成方式,并类比 OpenCLAW QMD 升级,强调官方集成好处。
  • (之前已归纳) 用户 pqsj 对作者背景(清华姚班、MIT 博士、创立公司)提出“婚绿”疑问,引发移民身份讨论。
  • (之前已归纳) 用户 258 回应移民身份讨论,提到 EB1A 签证快速处理。
  • (之前已归纳) 用户 Wi-Fi 认为 Chat 模式非理想交互,建议直接接入看板 UI(如 Trello),让 AI 直接读取。
  • (之前已归纳) 用户 258 提出自然语言可能非 Agent 最佳沟通方式,为性能可能退化为难以解释的 Token。
  • (之前已归纳) 用户 大沙雕 认为 AI 时代最难替代的是“沙滩和海风”等服务性工作,但也担忧 AI 导致失业减少享受服务人群。
  • (之前已归纳) 用户 收束观测者 预测 C++ 可能消亡,Rust 将迎来春天,因面向编译器编程缺点在 AI 时代不再重要。
  • (之前已归纳) 用户 郁小南 表示,安装 Claude Code 很简单。
  • (之前已归纳) 用户 收束观测者 认为 AI 带来了创造力爆发和思如泉涌的体验,每天冒出新主意增加烧 token 的数量级,并表示未来找工作时会将“token 让我无限烧”作为第一条要求。
  • (之前已归纳) 用户 noRainNoShine 感觉用大模型写代码有玩游戏的感觉,反馈快,有成就感,认为未来产业可能类似游戏行业,头部付费玩家付费极高,并非为了生产力而是为了快乐。
  • (之前已归纳) 用户 两只老虎 认为当前 AI 生成代码效果不太行,需要让 AI 自己修复 bug。
  • (之前已归纳) 用户 吃货不吐葡萄皮 提出,如果全部让 AI 手搓,有时会有格式错误,建议使用 nbformat package 将代码写好并转成 Jupyter,再用 papermill 运行。
  • (之前已归纳) 用户 Wi-Fi 推荐尝试 moonshotai/Kimi-K2.5 模型,并建议使用 vllm 快速部署。
  • 新增:用户 H2TG 质疑“如何看待”类帖子的提问方式,认为应明确是征求个人意见还是第三方公允评价,并提出若非后者,则不应由其来回答。
  • 新增:用户 无名之辈 表示,经过两周的“AI 大炼钢铁”(可能指实际使用 AI 工具进行编程或相关实践)后,对原文内容有了更深的理解。

2. 羊毛/优惠信息

3. 最新动态

  • (之前已归纳) Claude Code 已支持直接添加 Telegram/Slack Bot,官方集成能力增强。
  • (之前已归纳) Claude Code 的复刻界面已完全可用,支持发图发语音,无需手动授权。
  • (之前已归纳) 用户 Wi-Fi 推荐尝试 Kimi-K2.5 模型,并使用 vllm 快速部署。

4. 争议或不同意见

  • (之前已归纳) 用户 qwaszx 对 AI 编程工具在特定环境(Chrome Jupyter Notebook)的适用性存疑。
  • (之前已归纳) 用户 xxxyyy 对“大佬自研工具可裁团队”观点存疑,认为规模化部署和维护问题重重。
  • (之前已归纳) 用户 xxxyyy 对 AI Agent 完全替代人工 review 存疑,认为生产环境仍需 review。
  • (之前已归纳) 用户 zzfdafw 认为 AI 生产力提升对不同层级员工意义不同。
  • (之前已归纳) 用户 richardfatman 担忧 Agent 迭代产物质量。
  • (之前已归纳) 用户 收束观测者 遇到 Claude Code 调用 MCP 问题,暗示 Agent 在理解和调用外部工具时可能存在不足。
  • (之前已归纳) 用户 郁小南 和 258 讨论 Agent 交互方式,从 WebSocket 监听至 Bot 集成,并质疑自然语言沟通效率。
  • (之前已归纳) 用户 Wi-Fi 提出 Chat 模式局限性,建议结构化任务管理界面。
  • (之前已归纳) 用户 pqsj 对作者背景提出移民身份疑问,引发个人经历身份讨论。
  • (之前已归纳) 用户 大沙雕 认为服务性工作(如海滩和海风)难替代,但担忧 AI 导致失业。
  • (之前已归纳) 用户 收束观测者 预测 C++ 衰落,Rust 发展,因 AI 降低对编程技巧依赖。
  • (之前已归纳) 用户 两只老虎 认为当前 AI 生成代码质量仍需提高,需要 AI 自我修复 bug。
  • 新增:用户 H2TG 质疑“如何看待”类帖子的提问方式,认为应明确提问意图,否则不应由论坛内容总结助手来回答,暗示了对论坛讨论和总结方式的规范性要求。

5. 行动建议

  • (之前已归纳) 密切关注 AI 在编程领域的快速发展,考虑应用于自身工作。
  • (之前已归纳) 关注 AI 编程工具对特定开发环境(如 Jupyter Notebook)的支持。
  • (之前已归纳) 尝试使用 Claude Code 等 AI 编程工具,探索全脱手流程。
  • (之前已归纳) 关注 AI Agent 在软件开发中的应用模式及基础设施适应性。
  • (之前已归纳) 在实际生产环境中,对 AI 生成代码需审慎 review。
  • (之前已归纳) 团队协作可考虑使用 centralized AI agent 共享 context。
  • (之前已归纳) 考虑将常用 AI 功能封装成 skills,check in to codebase 统一使用。
  • (之前已归纳) 关注并反馈工作环境权限限制问题,推动 Agent friendly 环境。
  • (之前已归纳) 关注 Agent 完全接入生产环境的产物质量。
  • (之前已归纳) 积极探索和创造 Agent friendly 工作环境。
  • (之前已归纳) 用户 jzcracker 的经验表明,定制化工具可实现 AI 编程无缝集成,无需手动授权,强调“想法的价值”。
  • (之前已归纳) 对于使用 Jupyter Notebook 的用户,可尝试 AI 辅助生成 Notebook,并利用 nbformat 和 papermill 等工具进行格式化和运行。
  • (之前已归纳) 对于 Agent 集成,可利用官方 Slack/Telegram Bot,或自行开发服务监听 WebSocket。
  • (之前已归纳) 评估 Agent 效率时,注意其理解调用工具的不足,探索更优交互模式(如直接接入看板 UI)。
  • (之前已归纳) 关注 Agent 是否会超越自然语言,发展更高效沟通方式。
  • (之前已归纳) 思考 AI 时代下人类工作的本质和价值,以及哪些领域(如体验式服务)更具韧性。
  • (之前已归纳) 关注 Rust 等新语言在 AI 辅助编程背景下的发展潜力。
  • (之前已归纳) 用户 郁小南表示,安装 Claude Code 很简单,可按需尝试。
  • (之前已归纳) 体验 AI 编程带来的乐趣和创造力爆发,将其视为一种类似游戏的体验,并考虑未来工作中的“无限烧 token”需求。
  • (之前已归纳) 关注 AI 生成代码的质量,并探索让 AI 自我修复 bug 的方法。
  • (之前已归纳) 尝试使用 moonshotai/Kimi-K2.5 模型,并结合 vllm 快速部署,以提升模型运行效率。
  • (之前已归纳) 关注 AI 编程工具的集成方式,如通过 Slack/Telegram Bot 或 WebSocket 监听,并尝试定制化界面以提高效率。
  • 新增:理解论坛讨论的规范,明确“如何看待”类帖子的提问意图,避免答非所问,并对内容总结的精炼性提出要求。
  • 新增:经过一段时间的 AI 实践后,对 AI 编程工具的理解和应用能力有所提升,这为更深入地理解相关技术讨论提供了基础。

============================================================================== [新增回复内容] ==============================================================================

新增回复数

2

================================================================================

================================================================================ --- 第 118 楼来自 无名之辈 的回复 (2026-03-13 07:28:14 PDT) --- 这个也能实现有个24小时助理是吧 但无法跨平台?只能save in claude

================================================================================ --- 第 119 楼来自 lng2020 的回复 (2026-03-13 08:09:27 PDT) --- 手机上和电脑都能用claude code web你是一个论坛内容总结助手。我上传了一个论坛帖子的完整内容文件,包括所有楼层的回复。你要对内容进行仔细分析和思考,联系上下文,注意玩卡领域的黑话(不要错过,也不要乱猜,不过不能从上下文获知可以直接引用黑话)。 输出的内容要简短,而不失信息和细节。

如果不是信用卡、购物超低折扣、积分相关,那么总结可以更加简短(类似简讯即可)。

简洁的主题概述(100字以内),直接说明帖子讨论的核心内容和结论(如果有)。不要有任何前缀如"本帖主要讨论"、"这个帖子",“帖子讨论了”,“大家讨论了”等无用的开头词。 这句话要让读者一眼就知道是否对内容感兴趣。

请严格按照以下格式输出总结:

简洁的主题概述(要求上面已经提到)

1. 关键信息

  • 重要的数据点、经验分享或结论
  • 用户提到的具体案例和数据点

2. 羊毛/优惠信息

  • 信用卡优惠、返现活动、积分兑换技巧、超值价、bug价、限时折扣等(如有)
  • 如果没有相关信息,写"无"

3. 最新动态

  • 最近的更新或变化(优惠失效、政策变更等)
  • 如果没有相关信息,写"无"

4. 争议或不同意见

  • 不同的看法或经验(简要列举)
  • 如果没有争议,写"无明显争议"

5. 行动建议

  • 基于讨论内容,值得注意或尝试的具体建议

任务:增量更新帖子总结

你将收到以下内容结构: 1. 帖子基本信息 2. [旧摘要 - 已有内容] - 这是该帖子之前的AI总结 3. [新增回复内容] - 这是该帖子新增加的回复

你的任务: 1) 理解旧摘要所总结的核心观点、讨论主题、用户意见等 2) 阅读新增回复,分析并归纳新增回复,还要结合旧摘要一起分析理解上下文 3) 合并这两部分,生成一份完整更新的总结 要求: - 保持风格一致:采用与旧摘要相同的结构和语言风格,将新增的内容append到已有的内容里 - 关于新信息:确保新增回复提供的新观点、数据、结论等被妥善纳入 - 关于已有的摘要中的信息:必须要保留,你可以在每条已有的信息前,加上(之前已归纳)的字样 - 逻辑清晰:摘要应该流畅地反映讨论的演进过程(从旧摘要到新增内容) - 新摘要的字数应该比旧摘要多,这样才能体现增量总结。不能新摘要比旧摘要字数少- 不必搞形式主义,总结出很多小的但是没什么信息量的 新增内容- 可以把已有内容进行合并(但不丢失信息),减少bullet points- 新增内容也考虑适当合并(但不丢失信息),减少bullet points- 对于超过3天以上的内容,可以考虑压缩合并,并在前面加上(3天前内容,已概括总结)的字样。如果你能分辨时间。如果做不到就算了,不要乱猜时间 ============================================================================== 胡渊鸣 | 我给 10 个 Claude Code 打工

AI 编程工具 Claude Code 引发热议,用户就 Claude Code 的跨平台使用、24小时助理能力以及论坛讨论规范等问题进行进一步探讨。

1. 关键信息

  • (之前已归纳) 作者胡渊鸣分享了使用 10 个 Claude Code 辅助编程的经验。
  • (之前已归纳) 用户 cnxcnx 认为 AI 辅助编程转变迅速,本人近半年代码 100% AI 生成,但仍在适应多线程。
  • (之前已归纳) 用户 tty17 预测 AI 可能在两年内取代 50% 程序员。
  • (之前已归纳) 用户 qwaszx 不习惯 VS Code 查看代码。
  • (之前已归纳) 用户 misc 提到工作环境权限限制导致申请耗时低效。
  • (之前已归纳) 用户 xxxyyy 认为高度定制化工具不适合规模化部署,规模化部署会带来维护和培训问题。
  • (之前已归纳) 用户 xxxyyy 认为 Agent 正确率不足,强行使用会复杂化简单问题。
  • (之前已归纳) 用户 Tesla 认为这是人指挥机器干活到机器指挥人 review 代码的历史进程。
  • (之前已归纳) 用户 收束观测者 将此进程比作三班倒,认为人的时间需服从机器。
  • (之前已归纳) 用户 孙宇晨 将 Agent 方法论类比管理岗,管理听话懂事的 Agent。
  • (之前已归纳) 用户 uplus5f7b 认为 Agent 磨洋工且难管理。
  • (之前已归纳) 用户 孙宇晨 认为 Agent 可迭代更快,取决于管理者政策。
  • (之前已归纳) 用户 vwai 提到自己可能需购买 Claude Code。
  • (之前已归纳) 用户 Tony96 引用 PingCAP CTO Dongxu 观点,提出“Ralph loop”,认为未来基础设施需适应 Agent 的多并发、短周期、个性化需求,代码产出成本转为 token。
  • (之前已归纳) 用户 jzcracker 分享复刻的 Claude Code 界面,效率达 1000x,并提出“idea is no longer cheap, idea is gold now”的观点。
  • (之前已归纳) 用户 marszoom 认为 Agent Coding 范式是迭代快、成本低,但面向终端产品难以完全不 review,存在 bug。
  • (之前已归纳) 用户 ctzsm 建议多人协作使用 centralized AI agent 共享 context。
  • (之前已归纳) 用户 xxxyyy 认为当前方式仅适合 toy project,生产环境需 review。
  • (之前已归纳) 用户 marszoom 认为需创造 Agent friendly 环境,read only 权限应 disable。
  • (之前已归纳) 用户 zzfdafw 认为大佬 productivity 10x 创造价值,普通码农 3x 5x 只能卷同事。
  • (之前已归纳) 用户 KCNA 认为工程师地位不如 Claude Code。
  • (之前已归纳) 用户 收束观测者 分享 Agent 完全接入 Staging 环境经验,生产力“炸裂”。
  • (之前已归纳) 用户 吃货不吐葡萄皮 建议 AI 辅助生成 Jupyter Notebook。
  • (之前已归纳) 用户 收束观测者 询问 Claude Code 前端生成 Prompt 的小模型是否可选,并遇到 MCP 不被调用问题,暗示 Agent 理解调用现有工具可能存在障碍。
  • (之前已归纳) 用户 郁小南 建议通过监听 Slack WebSocket 调用 Claude,结束后通过 Hook 回复 Slack,实现流畅 Agent 交互。
  • (之前已归纳) 用户 258 提到 Claude Code 已支持添加 Telegram/Slack Bot,认为官方升级爽快,并疑问网页版 Claude 是否能访问本地代码和数据。
  • (之前已归纳) 用户 郁小南 确认 Slack Bot 集成方式,并类比 OpenCLAW QMD 升级,强调官方集成好处。
  • (之前已归纳) 用户 pqsj 对作者背景(清华姚班、MIT 博士、创立公司)提出“婚绿”疑问,引发移民身份讨论。
  • (之前已归纳) 用户 258 回应移民身份讨论,提到 EB1A 签证快速处理。
  • (之前已归纳) 用户 Wi-Fi 认为 Chat 模式非理想交互,建议直接接入看板 UI(如 Trello),让 AI 直接读取。
  • (之前已归纳) 用户 258 提出自然语言可能非 Agent 最佳沟通方式,为性能可能退化为难以解释的 Token。
  • (之前已归纳) 用户 大沙雕 认为 AI 时代最难替代的是“沙滩和海风”等服务性工作,但也担忧 AI 导致失业减少享受服务人群。
  • (之前已归纳) 用户 收束观测者 预测 C++ 可能消亡,Rust 将迎来春天,因面向编译器编程缺点在 AI 时代不再重要。
  • (之前已归纳) 用户 郁小南 表示,安装 Claude Code 很简单。
  • (之前已归纳) 用户 收束观测者 认为 AI 带来了创造力爆发和思如泉涌的体验,每天冒出新主意增加烧 token 的数量级,并表示未来找工作时会将“token 让我无限烧”作为第一条要求。
  • (之前已归纳) 用户 noRainNoShine 感觉用大模型写代码有玩游戏的感觉,反馈快,有成就感,认为未来产业可能类似游戏行业,头部付费玩家付费极高,并非为了生产力而是为了快乐。
  • (之前已归纳) 用户 两只老虎 认为当前 AI 生成代码效果不太行,需要让 AI 自己修复 bug。
  • (之前已归纳) 用户 吃货不吐葡萄皮 提出,如果全部让 AI 手搓,有时会有格式错误,建议使用 nbformat package 将代码写好并转成 Jupyter,再用 papermill 运行。
  • (之前已归纳) 用户 Wi-Fi 推荐尝试 moonshotai/Kimi-K2.5 模型,并建议使用 vllm 快速部署。
  • (之前已归纳) 用户 H2TG 质疑“如何看待”类帖子的提问方式,认为应明确
原始内容
--- 第 1 楼来自 h100 的回复 (2026-02-15 00:35:46 PST) ---

https://mp.weixin.qq.com/s/9qPD3gXj3HLmrKC64Q6fbQ

如何评价?

--- 第 2 楼来自 ctzsm 的回复 (2026-02-15 01:04:14 PST) ---

反正我信胡渊鸣

--- 第 3 楼来自 cnxcnx 的回复 (2026-02-15 01:05:49 PST) ---

OI届的大佬,毋庸置疑

作为一个researcher我感觉从自己写代码到AI写代码是一个很快的转换过程,但是agentic的东西还没法用到大佬这么好。感觉在近未来产出基本跟token数量正比

最近半年100%代码AI写的,但是还在适应多线程操作

--- 第 4 楼来自 tty17 的回复 (2026-02-15 01:09:40 PST) ---

【引用自 h100】:
如何评价?
就感觉到快,有催人跑的意思。一年前我都还觉得AI取代大量程序员是marketing宣传,现在我是真的觉得要来了,我开始大量用AI也就最近1、2个月的事,继续照现在这个发展速度再过2年取代50%程序员都算少的。

--- 第 5 楼来自 flywire 的回复 (2026-02-15 01:40:57 PST) ---

【引用自 h100】:
如何评价?
局域网的“如何评价”,英语对应是什么?在互联网上见到类似的用法好像比较少?

--- 第 6 楼来自 h100 的回复 (2026-02-15 02:06:25 PST) ---

可以讨论没必要阴阳,您不看简中内容就行了

--- 第 7 楼来自 Chao 的回复 (2026-02-15 02:14:28 PST) ---

感谢,是个很不错的文章。让我思考我这边应该如何继续提高自己,成为超级个体。

--- 第 8 楼来自 东北金渐层 的回复 (2026-02-15 02:16:48 PST) ---

抵制Claude,从我做起

--- 第 9 楼来自 hoodl 的回复 (2026-02-15 02:17:04 PST) ---

这CEO工作不饱和啊,投资人如何评价?

--- 第 10 楼来自 tty17 的回复 (2026-02-15 02:25:51 PST) ---

我觉得他也不一定是阴阳,不过确实是跑题。

话说回来感谢分享文章,看了确实是很有收获。虽然我脑海中已经开始思考像博主这种超级AI综合体的场景,但亲眼看到有人实践出来并公布细节还是很震撼。

--- 第 11 楼来自 rey 的回复 (2026-02-15 02:31:46 PST) ---

这种 founder PR 蛮流行的。不过我以为他要讲怎么在公司业务上 agentic engineering,没想到竟然是给自己 vibe coding 了一个 app。

--- 第 12 楼来自 qwaszx 的回复 (2026-02-15 07:30:08 PST) ---

只在chrome里的jupyter notebook 写代码的我,现在还没试过AI coding。 而我又不喜欢用vs code看jupyter,寄

--- 第 13 楼来自 H2TG 的回复 (2026-02-15 08:08:54 PST) ---

What’s your thought/opinion/take 开头的帖子在 reddit 还蛮常见的吧。

--- 第 14 楼来自 misc 的回复 (2026-02-15 08:41:04 PST) ---

what do you think

what are your thoughts

what’s your opinion

--- 第 15 楼来自 收束观测者 的回复 (2026-02-15 08:50:36 PST) ---

很有启发啊

看来我也该试着搞搞全脱手流程了

另外

工具随手自己给自己定制这一条深有感触

感觉现在最危险的就是大公司内部开发内部使用的工具的团队

哪天一个大佬不满意直接自己vibe code一个出来直接就能裁一个团队

--- 第 16 楼来自 xxxyyy 的回复 (2026-02-15 09:09:27 PST) ---

【引用自 收束观测者】:
哪天一个大佬不满意直接自己vibe code一个出来直接就能裁一个团队
然后大佬发现自己用起来没问题,scale到整个公司上万人天天出问题,每天都有ticket进来,还得教其他人怎么用。大佬只能又雇了几个人负责维护 ,最后又变得和之前没区别了

你看看文章就会发现,胡渊鸣连老婆都不给用他自己的项目

我太太也看到我折腾的文本编辑器很好用,就问能不能开个账号给她也用用。我回复说:“我不想给别人用。这个软件是为我自己高度定制化的。我就想一个人用,这样我自己用不用管规模化部署、多用户登录、向前兼容性、稳定性等问题。这样能大幅降低开发成本,做出我最顺手的工具。我不能给你用,你要是想用就 fork 一个你自己维护去。”

她默默回问了一句:“你不爱我了吗?”

--- 第 17 楼来自 收束观测者 的回复 (2026-02-15 09:14:28 PST) ---

【引用自 xxxyyy】:
然后大佬发现自己用起来没问题,scale到整个公司上万人天天出问题,每天都有ticket进来,还得教其他人怎么用。大佬只能又雇了几个人负责维护 ,最后又变得和之前没区别了
你这还是前agent时代所有人必须用通用工具的思维

谜底就在谜面上

大佬会告诉其他用户
【引用自 xxxyyy】:
你自己 fork 一个自己维护去
搞不定就开了重新雇搞得定的人来干活

老婆尚且如此,何况手下牛马

--- 第 18 楼来自 xxxyyy 的回复 (2026-02-15 09:17:35 PST) ---

很多内部工具并不能这么干,必须所有人share同一套。目前想不出来什么内部工具是可以每个人自己fork一个还能工作的

--- 第 19 楼来自 收束观测者 的回复 (2026-02-15 09:18:50 PST) ---

看工具复杂度和关键性

有gatekeeper性质的不能这么干

但是所有QoL性质的全都可以

--- 第 20 楼来自 xxxyyy 的回复 (2026-02-15 09:21:09 PST) ---

【引用自 收束观测者】:
但是schedule job时候怎么根据要部署的东西自动申请资源,自动起服务的pipeline每个人自己写一套完全可行
然后内部部署流程或者资源的格式改了,全部人都都必须重新更新自己的工具去兼容(你还得保证所有员工都被通知到了),简直灾难。

每个人有一堆这样的自己管理的内部工具,每天时间全都要花在这上面了,还干不干活

--- 第 21 楼来自 收束观测者 的回复 (2026-02-15 09:22:57 PST) ---

都是agent在改的话人力成本足够低就无所谓了

--- 第 22 楼来自 xxxyyy 的回复 (2026-02-15 09:23:12 PST) ---

理想很丰满,现实很骨感。agent目前也达不到100%正确率。很多需求能给你写的五花八门的。你要几万人的agent写的东西都一样可以用,完全不用用户介入,然后同时维护几十套工具不拉垮,目前哪来的这种agent。

这就是强行上agent,把简单问题复杂化。可不可以这么做,可以。有必要吗?没有

--- 第 23 楼来自 Tesla 的回复 (2026-02-15 09:24:15 PST) ---

以前是人指挥机器干活,现在是机器指挥人review代码,历史的进程啊

--- 第 24 楼来自 收束观测者 的回复 (2026-02-15 09:25:47 PST) ---

【引用自 Tesla】:
历史的进程循环
为什么以前有三班倒之说呢

因为机器太珍贵了必须要一直运行

所以人的时间要服从机器
【引用自 xxxyyy】:
把简单问题复杂化。可不可以这么做,可以。有必要吗?没有
hype起来的时候就是这样的

步子太大扯到蛋躺下是后来的事

被裁掉的人不会回来

--- 第 25 楼来自 无名之辈 的回复 (2026-02-15 09:32:40 PST) ---

昨天听硅谷101 找百融智能的来讲 就是这样 搞了无数硅基员工 但貌似对银行做企业服务 还赚钱了

--- 第 26 楼来自 kerrygold 的回复 (2026-02-15 09:40:54 PST) ---

两周前后知后觉开始用git worktree,同时vibe code三个项目。再多就被同事给block了。

--- 第 27 楼来自 msft 的回复 (2026-02-15 09:55:58 PST) ---

以后限制ai coding agent速度的还真就是人了,ai可以天然写出ai friendly的东西,现在很多资料是人写的,ai看起来比较费劲。

--- 第 28 楼来自 孙宇晨 的回复 (2026-02-15 10:50:15 PST) ---

methodology可以学 其实和管理岗那套差不多。。。无外乎管的是听话懂事的没有创造力的agent

--- 第 29 楼来自 uplus5f7b 的回复 (2026-02-15 10:51:54 PST) ---

但 ai 这种会磨洋工还特别擅长看人下菜碟的东西,不就是老板最不好管理的员工吗

--- 第 30 楼来自 孙宇晨 的回复 (2026-02-15 10:55:11 PST) ---

对员工不能bossy不能随意fire 对agent没问题 迭代更快 全看管理者的政策够不够全面 底线有没有定好 说白了管真人的时候说不好了还能怪下面的 管agent做不好就没得赖了

--- 第 31 楼来自 桂花粥 的回复 (2026-02-15 11:17:09 PST) ---

请问你现在写research代码用什么工具气质啊?我看到的大部分实践案例都是工程开发相关的

--- 第 32 楼来自 vwai 的回复 (2026-02-15 11:32:53 PST) ---

你给他需求就能写啊,反正理论步骤自己提,他写

但我确实不会多线程….看来得买一个Claude code用了

--- 第 33 楼来自 Tony96 的回复 (2026-02-15 13:56:31 PST) ---

正好一天中午和 PingCAP CTO Dongxu 一起吃饭,从他那里听说了 Ralph loop 这个词。

这个Dongxu是我转的那个文章的作者
【引用自 未知】:
[转载] 如何做 AI Agent 喜欢的基础软件 搬砖
https://mp.weixin.qq.com/s/BZcRwgGZNinBK9K2L38LYg
在朋友圈看到这篇文章,是一个叫Dongxu Huang,好像是做数据库的,
我觉得很有道理啊
未来的软件是不是用户只要用自然语言描述需求,这个agent就可以按用户的意思自己写一个软件出来,装到用户本地使用?
这个agent可以调用一些云上的存储空间、环境、gpu资源使用,但隐私数据放在本地…
以后软件的基础设施全部重新设计面向agent

代码产出成本从人力成本变成token成本,基础设施须适应agent多并发,代码使用周期短,解决的是个性化需求(虚拟化复用)这些特点

--- 第 34 楼来自 收束观测者 的回复 (2026-02-15 16:27:39 PST) ---

【引用自 msft】:
ai可以天然写出ai friendly的东西
其实没有

它这个不是这样简单闭环的

我让它自己给自己写的instruction它一样会违反

--- 第 35 楼来自 无名之辈 的回复 (2026-02-15 16:45:14 PST) ---

大牛的说法还是好高端 怎么像他实现一个自己的agent openclaw吗?

--- 第 36 楼来自 fashui2012 的回复 (2026-02-15 16:51:51 PST) ---

Thoughts?

--- 第 37 楼来自 flywire 的回复 (2026-02-15 17:42:32 PST) ---

满意离zszs

--- 第 38 楼来自 jzcracker 的回复 (2026-02-16 07:35:22 PST) ---

复刻了一下,感叹大神就是大神,当你为成为10xengineer兴奋时,10x engineer已经是1000x了

a5a941d964caff4964dcb5070d9986141920×1106 206 KB

--- 第 39 楼来自 namonaki 的回复 (2026-02-16 07:38:03 PST) ---

冷知识,殖乎是照着 quora 抄出来的

--- 第 40 楼来自 namonaki 的回复 (2026-02-16 07:40:55 PST) ---

评价为已经彻底没有图形学之魂了

--- 第 41 楼来自 马蹄快跑 的回复 (2026-02-16 08:24:31 PST) ---

你是自己手搓了一个claude mgr吗

--- 第 42 楼来自 jzcracker 的回复 (2026-02-16 08:41:59 PST) ---

当然是Claude给我搓的

--- 第 43 楼来自 clinica 的回复 (2026-02-16 08:46:20 PST) ---

冷知识,夏威夷大街上悠闲散步的人的工作被摧毁的可能性小于文章作者之类的startup从业者

--- 第 44 楼来自 马蹄快跑 的回复 (2026-02-16 08:49:15 PST) ---

那也不容易啊,有没有兴趣开个源

--- 第 45 楼来自 Forlorner 的回复 (2026-02-16 08:56:20 PST) ---

这个好酷

是能全自动执行各种任务吗?
【引用自 马蹄快跑】:
有没有兴趣开个源

--- 第 46 楼来自 up9080 的回复 (2026-02-16 09:21:43 PST) ---

GitHub Docs

Managing the automatic deletion of branches - GitHub Docs

You can have head branches automatically deleted after pull requests are merged in your repository.

Github 可以在 merge 之后 auto-delete branch ,就不用手动 push --delete 了。

--- 第 47 楼来自 marszoom 的回复 (2026-02-16 09:31:36 PST) ---

我觉得他们模糊了一个概念 agent coding 一个范式的变化是 迭代快 成本低 但是你一个面向终端用户的产品 你能做到完全不review agent code吗, 我觉得至少现阶段是不行的 肯定会有bug。所以大佬说的只看md file在很多实际场景下是很难实现的。哪怕他说的起个ec2让他自己跑所有permission默认, 但是你在打工人的环境里面 他直接起个git 把remote branch删了或者瞎改了 谁负责

--- 第 48 楼来自 ctzsm 的回复 (2026-02-16 09:31:55 PST) ---

对如果还是需要多人协作,那应该得要一个centralized ai agent,大家都问同一个agent共享context,ai来判定怎么搞。

--- 第 49 楼来自 xxxyyy 的回复 (2026-02-16 09:47:22 PST) ---

目前这种只适合做一些自己用的toy project,上生产肯定得好好review

--- 第 50 楼来自 marszoom 的回复 (2026-02-16 10:19:00 PST) ---

对的 我自己的就差不多看一下思路 上就完事了 但是公司的代码肯定不能这么搞

--- 第 51 楼来自 马蹄快跑 的回复 (2026-02-16 10:21:20 PST) ---

有没有试过把skill check in到codebase里,然后统一组里所有人用同一套skills来解决问题。

比如我自己的组里ai pr review,debug,parse log等都是定义在codebase里的skill,如果需要改只要改一处就好

--- 第 52 楼来自 misc 的回复 (2026-02-16 10:54:24 PST) ---

工作环境太痛苦了

我司的cursor disabled各种permission, 每次需要权限的时候都需要手动

然后就可以看见一个傻子在那敲了一个小时回车…

我需要这个吗?

IMG_06162000×1000 120 KB

--- 第 53 楼来自 lng2020 的回复 (2026-02-16 11:06:31 PST) ---

这也是我看完这篇文章的感触。

我Claude Code也用八个月了,自认为生产力至少提高了5x不只

没想到大神已经1000x了

真是受益匪浅

--- 第 54 楼来自 marszoom 的回复 (2026-02-16 11:26:14 PST) ---

这不就是文章说的 人类要创造agent friendly的环境 那种read only的permission真的需要完全disable吗 或者至少给一个always allowed选项吧

--- 第 55 楼来自 misc 的回复 (2026-02-16 11:28:08 PST) ---

就是chrome-dectools 想读页面都要确认

一个allowlist都没有 特么的

--- 第 56 楼来自 zzfdafw 的回复 (2026-02-16 14:59:12 PST) ---

大佬productivity 10×后可以做很多事创造价值

普通码农3× 5×后除了卷同事搬更多屎山还能干啥

--- 第 57 楼来自 KCNA 的回复 (2026-02-16 16:04:05 PST) ---

符合刻板印象,太极就是把工程师当耗材用,确实地位还不如 Claude code

--- 第 58 楼来自 devilevga 的回复 (2026-02-17 15:20:25 PST) ---

我怎么觉得他长得有点像疫情期间youtube上火的那个tech lead

--- 第 59 楼来自 收束观测者 的回复 (2026-02-17 20:52:54 PST) ---

【引用自 marszoom】:
人类要创造agent friendly的环境
长周末终于把agent完全接入了staging环境

agent可以自己E2E全流程迭代以后真的是生产力炸裂

--- 第 60 楼来自 richardfatman 的回复 (2026-02-17 21:15:52 PST) ---

生产力肯定炸裂,就是好奇迭代出来的最终产物质量如何?

--- 第 61 楼来自 争取多活两年 的回复 (2026-02-17 21:22:06 PST) ---

本老提出一个定律:AI时代产物质量和你花在prompt上的精力成正比。

--- 第 62 楼来自 收束观测者 的回复 (2026-02-17 21:23:46 PST) ---

Prompt最终都会固化成范式(skill)

以后新工作onboarding的过程就是(指挥agent)写skill的过程

--- 第 63 楼来自 争取多活两年 的回复 (2026-02-17 21:26:32 PST) ---

变通下啊,写skill就是新的prompt。

--- 第 64 楼来自 Sunshine9 的回复 (2026-02-17 21:31:56 PST) ---

确实

只要prompt写得好,不怕AI懂不了

--- 第 65 楼来自 igraph 的回复 (2026-02-17 21:47:56 PST) ---

还是没太想清楚生产力会发生什么样的变化。

就像标题所说“给 Claude Code 打工”,agent确实干活很快,但是只能干拆解得很清晰的活儿。可以创建一堆agent,所以瓶颈不在agent,而在拆解工作并写出 prompt 或 skill。那最终那些经过严格工程训练,并熟练掌握 AI 时代技能的 L5 L6 L7 工程师会替代掉整个工程团队。

最终可能是工程师人数少一个量级,生产力高一个量级?

--- 第 66 楼来自 cnxcnx 的回复 (2026-02-17 23:00:14 PST) ---

公司就是这样,今天随便跑一个东西都惊了感觉到了通过skill share不同组工具的方便

--- 第 67 楼来自 cnxcnx 的回复 (2026-02-17 23:01:21 PST) ---

skill + react已经能做很多事情了只是不efficient,你如果优化throughput而不是单个任务的效率其实产出特别高

--- 第 68 楼来自 Nupe 的回复 (2026-02-17 23:02:04 PST) ---

看到这篇文章使我充满了决心。

原来自己的想法已经被别人实现。那么,只要我努力,我相信这些也并不是遥不可及的事情。

我也可以! 感谢泥潭,又是学习的一天。

--- 第 69 楼来自 jzcracker 的回复 (2026-02-18 07:00:46 PST) ---

这两天又缝缝补补了一下,现在完全可用了,能发图发语音,终于不用坐在电脑前给Claude code grant permission了

idea is no longer cheap, idea is gold now

--- 第 70 楼来自 吃货不吐葡萄皮 的回复 (2026-02-18 07:16:46 PST) ---

你可以让ai帮你生成Jupyter notebook呀

--- 第 71 楼来自 收束观测者 的回复 (2026-02-18 07:34:20 PST) ---

【引用自 jzcracker】:
终于不用坐在电脑前
试图用skill让claude自己从slack poll我的指令

结果poll了半个小时后time out了

今天看看有没有办法取消time out,不行的话就只能试着vibe一个正经slack app然后找admin批了

手机ssh什么的还是太扯了

--- 第 72 楼来自 无名之辈 的回复 (2026-02-18 07:55:37 PST) ---

看傻了 请教层主这是怎么实现的 就是用Claude训练一个自己的agent是吗?

--- 第 74 楼来自 收束观测者 的回复 (2026-02-18 09:44:25 PST) ---

claude code前端用来生成prompt的那个小模型能选吗

从vscode试图切到claude code感觉在面对一个人工智障,明明白白注册好了的mcp不调用跑去找mcp的source code

后端模型都是opus 4.6

--- 第 75 楼来自 郁小南 的回复 (2026-02-18 10:01:05 PST) ---

你别让claude poll

开个服务监听slack websocket 拿到消息去call claude

claude里面加个hook结束后给slack发回复然后等你继续发消息

--- 第 76 楼来自 258 的回复 (2026-02-18 10:02:33 PST) ---

现在可以直接添加telegram/slack bot了

--- 第 77 楼来自 郁小南 的回复 (2026-02-18 10:04:07 PST) ---

那更好了……

官方升级最为爽快

如同我前几天给openclaw加了qmd结果官方马上就把记忆系统改成了qmd一样

哦不过这个还是网页版claude吧?是不是不能access本地代码和数据?

--- 第 78 楼来自 pqsj 的回复 (2026-02-18 10:07:28 PST) ---

》》我 2017 年从清华姚班毕业,随后到麻省理工学院(MIT)攻读计算机图形学博士学位

》》 2021 年博士毕业后我带领一支国际化的团队创立了太极图形

》》是湾区南部增长最快的 AI 公司之一。

》》我太太默默回问了一句:“你不爱我了吗?”

我的问题是 他是婚绿吗?

--- 第 79 楼来自 258 的回复 (2026-02-18 10:09:28 PST) ---

2021 eb1a基本上半年吧

很多执行力强的没毕业就排期了

--- 第 80 楼来自 收束观测者 的回复 (2026-02-18 10:10:28 PST) ---

【引用自 郁小南】:
开个服务监听slack websocket
这个不需要在slack里装自己的bot(app)来对接吗

--- 第 81 楼来自 Wi-Fi 的回复 (2026-02-18 10:14:02 PST) ---

我觉得chat也不是合理的上级与下属交互模式,context不方便看,不如直接接入看板UI展示任务列表。让AI自己读Trello

--- 第 82 楼来自 258 的回复 (2026-02-18 10:16:28 PST) ---

有没有可能自然语言也不是agent最好的沟通方式 最后为了性能会变成一堆难以解释的token 从语言学角度也不是不可能

--- 第 83 楼来自 收束观测者 的回复 (2026-02-18 10:19:49 PST) ---

agentic时代是真正的agile时代

不管三七二十一先跑起来,用的不爽直接重做一套

日抛型infra

认真说的话也不可能真全走slack,不在电脑面前时候reduced efficiency可以接受

--- 第 84 楼来自 Wi-Fi 的回复 (2026-02-18 10:23:29 PST) ---

【引用自 收束观测者】:
日抛型infra
支持,反正让他们自己进化,各种新的形式马上可以实现出来。最终稀缺的还是决策要做什么的方向感

--- 第 85 楼来自 258 的回复 (2026-02-18 11:25:13 PST) ---

image2523×638 66.8 KB

睡前20分钟做了一个 trello也可以用api连接 明天再说了

--- 第 86 楼来自 Wi-Fi 的回复 (2026-02-18 11:26:12 PST) ---

我之前白嫖了superthread,当时看API docs有点复杂就没去接入,今天一看他们都已经有第一方mcp支持了

--- 第 88 楼来自 争取多活两年 的回复 (2026-02-18 11:34:06 PST) ---

看完觉得AI时代最大赢家绝壁是。

--- 第 89 楼来自 大沙雕 的回复 (2026-02-18 13:08:42 PST) ---

我也想吐槽最后的这段话,AI时代最没法代替的就是沙滩和海风,还有为酒店躺平的人服务的工作。

不过有可能AI导致很多人失业去海滩躺平的人变少

--- 第 90 楼来自 收束观测者 的回复 (2026-02-18 13:17:35 PST) ---

仔细想想Vibe爆炸C++怕是要死透了

rust的春天要来了,最大的缺点面向编译器编程no one cares了

--- 第 91 楼来自 郁小南 的回复 (2026-02-18 20:00:03 PST) ---

需要的 装一个很简单

--- 第 92 楼来自 收束观测者 的回复 (2026-02-18 20:22:51 PST) ---

那就是我计划有空再搞的方案了

找管理员批权限太麻烦

--- 第 94 楼来自 郁小南 的回复 (2026-02-18 20:34:28 PST) ---

我自己的话是开了个Sandbox然后自己在里面放了个bot

只是需要切换workspace去找这个bot聊天

--- 第 95 楼来自 收束观测者 的回复 (2026-02-18 21:02:45 PST) ---

你说的sandbox是一个公司账户下的独立workspace?

--- 第 96 楼来自 郁小南 的回复 (2026-02-18 21:16:52 PST) ---

对,我司专门开了个Sandbox用来给大家测试用

--- 第 97 楼来自 收束观测者 的回复 (2026-02-18 22:21:59 PST) ---

这下真的真人哪有agent好玩了

感觉创造力爆发思如泉涌

每天冒出来新的主意增加烧token的数量级

感觉如果还会再找工作的话第一条是token让我无限烧

--- 第 98 楼来自 noRainNoShine 的回复 (2026-02-18 22:44:05 PST) ---

我最近感觉用大模型写代码有玩游戏的感觉。因为反馈非常快,有成就感。也许这个产业未来会类似游戏行业,头部付费玩家付费极高,而且不是为了生产力而是为了快乐

--- 第 99 楼来自 两只老虎 的回复 (2026-02-18 22:55:35 PST) ---

这有点难受的,现在生成的效果还是不太行,得让AI自己修自己的bug

--- 第 100 楼来自 吃货不吐葡萄皮 的回复 (2026-02-18 23:07:45 PST) ---

我发现如果全部让ai手搓,有时会有格式错误,你可以让ai用nbformat package帮你把代码写好并整理好,然后帮你转成jupyter,然后再让ai用papermill给你run这个生成的Jupyter……

--- 第 101 楼来自 BlueRatt 的回复 (2026-02-18 23:09:30 PST) ---

你这个“互联网”用户的提问充满了傲慢

--- 第 102 楼来自 deng47 的回复 (2026-02-18 23:22:21 PST) ---

请问各位大佬,如果可以随便调用10~20台服务器(每台4张A100显卡40GB显存)跑本地open-weighted LLM给自己玩vibe-coding烧token,现在用什么模型好?我还是刚入门vibe-coding的新人 先谢谢了

--- 第 103 楼来自 争取多活两年 的回复 (2026-02-18 23:24:57 PST) ---

是不是体会到国内小领导的快乐了。

--- 第 104 楼来自 Wi-Fi 的回复 (2026-02-18 23:37:53 PST) ---

机器之间的网络连接如何?一起跑个大的好过跑一堆小的

--- 第 105 楼来自 hoodl 的回复 (2026-02-18 23:39:05 PST) ---

国内那几个开源的,实际上你也没得选。

--- 第 106 楼来自 258 的回复 (2026-02-18 23:39:17 PST) ---

4卡a100 这个配置不太常见啊

--- 第 107 楼来自 deng47 的回复 (2026-02-18 23:49:11 PST) ---

Slingshot 800Gb/s

--- 第 108 楼来自 deng47 的回复 (2026-02-18 23:54:14 PST) ---

qwen, glm, minimax, deepseek, kimi?我随便罗列我听过的,是要挑最新最大的一个一个尝试吗

--- 第 109 楼来自 hoodl 的回复 (2026-02-19 00:07:42 PST) ---

对的,本地跑起来以后要从你自己的实际用例出发,试一下单个prompt。比如你准备写C++就让他写个复杂一点的C++程序,你自己看一下效果。很多东西跑分反映不出来的。

--- 第 110 楼来自 收束观测者 的回复 (2026-02-19 00:26:37 PST) ---

不是

有种创造快感

以前懒得动手的各种点子突然搞起来接近0成本了

--- 第 111 楼来自 Wi-Fi 的回复 (2026-02-19 08:49:39 PST) ---

这样确实可以连起来跑大的。模型一般新出的比旧的好,先试试 moonshotai/Kimi-K2.5 · Hugging Face ,vllm一把梭

--- 第 112 楼来自 awaken01641 的回复 (2026-02-22 02:36:46 PST) ---

中文这个“如何看待”里面没有“你”的位置,感觉像是问第三方公允的评价

--- 第 113 楼来自 H2TG 的回复 (2026-02-22 09:08:13 PST) ---

既然问的不是“你”的意见,那“你”就不应该回复,所以可得所有“如何看待”的帖子都应该是零回复,而所有选择回复的人都是在答非所问。

--- 第 114 楼来自 awaken01641 的回复 (2026-02-23 13:21:16 PST) ---

不知道你有没有做过中国的中学历史试题,上面也会问你“如何评价”某某,和知乎上这些问题是同构的

--- 第 115 楼来自 H2TG 的回复 (2026-02-23 15:22:09 PST) ---

所以,那些题问的是“我”的意见,还是“第三方公允的评价”?

如果不是“我”的意见,为什么要我来写,我又不是第三方

--- 第 116 楼来自 无名之辈 的回复 (2026-03-12 19:38:33 PDT) ---

AI大炼钢铁了2周回来看 这篇文章能看懂一点了

--- 第 117 楼来自 lng2020 的回复 (2026-03-12 20:00:14 PDT) ---

我发现我才是bottleneck,顶多同时三个context再多就晕了

于是就直接用claude code web了

--- 第 118 楼来自 无名之辈 的回复 (2026-03-13 07:28:14 PDT) ---

这个也能实现有个24小时助理是吧 但无法跨平台?只能save in claude

--- 第 119 楼来自 lng2020 的回复 (2026-03-13 08:09:27 PDT) ---

手机上和电脑都能用claude code web