Claude Code 自动化工作流拆解：模型之外，软件工程如何沉淀核心资产

昨天关于AI-First 和软件工程门槛的文章下面，有位读者提出了一个很实际的问题：

但是有一点，模型不是公司可沉淀的资产，如果一套系统围绕模型开发，那万一模型哪天不给用了，或者成本涨了呢？

这个问题的确点中了要害。很多关于“AI 提效”的讨论，常常默认模型永远可用、价格稳定、接口兼容。但在真实的公司系统中，这些都不能被视为理所当然。

模型的能力可以被调用，但它本身很难成为一家公司长期、可控的资产。供应商的策略会变，价格会波动，API 也可能因为合规、地域或产品线调整而中断。将一套系统的核心价值完全绑定在某个特定模型上，风险不言而喻。

最近，一个在 X 上浏览量超过 287 万的帖子，恰好可以带我们深入思考这个问题。帖子标题很直接：
“Google engineer automated 80% of his work with Claude Code.”

根据帖子描述，一位拥有 11 年经验的谷歌工程师，利用 Claude Code 和一个简单的 .NET 应用，自动化了 80% 的工作。现在他每天只需要工作 2-3 小时进行审查和测试，其余时间让系统自行运行。

这类帖子很容易让人被数字吸引，但我阅读时先按下了暂停键。我未能找到可以独立证实“谷歌工程师”身份的一手资料。原帖没有提供姓名、公开主页、代码仓库或当事人的直接说明，也没有给出完整的系统代码。“80%自动化”、“28，000 美元被动收入”、“每天只工作 2-3 小时”这些数字，更像是传播中的叙事钩子，并不适合直接作为公司决策的依据。

帖子中甚至有一个细节更能说明其风格：“Teams 状态保持在线，鼠标每分钟自动移动一次。” 这更像是办公室摸鱼的幻想，而非严肃的工程经验。中文转载稿件最后也专门提醒了案例的真实性问题。

因此，我不打算把它写成一个传奇故事，而是更适合将其拆解为一个工作流样本，进行技术分析。

相比这些尚无法核实的数字，我更想探讨另一个问题：

如果模型本身不是公司可控的资产，那么基于 Claude Code 的自动化，到底能沉淀下什么真正有价值的东西？

我的看法是：价值可以沉淀在模型之外的那层软件工程接口里。

具体来说，包括：任务如何进入系统、什么样的状态才可以交给 Agent 处理、Agent 如何获取上下文、代码在哪个分支执行、测试如何证明没有引入回归、PR 由谁验收、失败后如何回滚、成本如何被监控。

这些东西一旦清晰、结构化，未来无论是切换为 Claude Code、Codex、Gemini CLI，还是某个未来的内部 Agent，都还有迁移的空间。反之，如果只剩几段聊天记录和临时脚本，模型一换，很多东西就得推倒重来。

这也是我觉得原帖值得被拆解的地方。关键不在于“80%”这个数字，而在于它勾勒出了一条典型的软件工程链路：

Issue 进入 -> 判断是否就绪 -> 就绪后开分支实现 -> 实现后发起 PR -> PR 评论回流 -> 系统根据评论继续修改 -> 人类始终负责最终验收和合并。

AI 自动化首先消化的是重复性劳动，但最终放大的，其实是工程系统本身的能力。

在梳理 Claude Code、Harness、Managed Agents 和 AI-First 相关话题时，我越来越感觉到它们都指向同一个核心：Claude Code 不是一个孤立的工具，Coding Agent 也不只是一个模型。它们能否有效运行，越来越取决于包裹在模型外面的那层软件工程系统。

这个系统大体可以分为三层：

• 配置即代码：将 CLAUDE.md / rules / agents / commands / skills / hooks / MCP 沉淀到代码仓库中，使之从个人技巧转变为团队资产。
• 运行时与 Harness：让 Agent 能够在真实的工程环境中稳定地执行长周期任务，而不是依赖单次对话。
• 软件工程门槛：多装几个 Agent 解决不了根本问题，必须有一条稳健的工程链路来托住整个自动化流程。

这个 287 万浏览的帖子，恰好将这三层塞进了一个最小化的闭环里。

先说结论

• 关于模型资产：模型确实不是公司可沉淀的核心资产。围绕单一模型构建系统，会面临供应、成本和合规风险。
• 关于原帖案例：文中的“谷歌工程师”、80%自动化率、2.8万美元被动收入等，证据链不足。我们应将其视为一个自动化工作流的设计思路参考，而非既定事实。
• 可沉淀的价值：真正能留下来的，是任务入口、项目规则、测试体系、权限控制、日志、回滚机制、成本预算和验收流程这些模型之外的软件工程接口。
• 核心闭环：更值得关注的是 Issue -> 分诊 -> 分支开发 -> PR -> Review -> 再修改 这条工作流闭环。“减少工作时间”只是它的叙事外壳。
• 工程现实：原帖说“通往全面自动化只隔着三个命令和一个文件”。但从工程角度看，中间隔着的是任务准入、项目规则、测试、权限、日志、回滚和验收机制。
• CLAUDE.md 的价值：CLAUDE.md 的价值在于将项目级别的行为约束写成 Agent 每次都能读取的“工程接口”，不能仅将其视为提示词玄学。
• 开源仓库的用法：像 everything-claude-code 这类仓库更像是组件货架和配置基线，应优先学习其结构与边界设计，而非全量安装。
• 自动化门槛：自动化的关键门槛有三层：任务准入、执行隔离、反馈验收。缺少任何一层，都会从“自动化”滑向“自动制造技术债”。
• 实施路径：配置即代码是第一步，执行闭环是第二步，团队治理是第三步。三层都到位，自动化才稳定。
• 个人与团队之别：个人自动化案例不能直接外推到团队。个人可以容忍脚本粗糙、权限宽松、自己修复失败；团队则不行。
• 落地建议：个人可以从“只读分诊”开始尝试，不要一上来就让 Agent 自动合并代码。团队要复制这类模式，应先补全测试、CI、权限、日志、回滚、成本预算和审计，而不是盲目增加 Agent 数量。

CLAUDE.md：先别神化，理解其工程接口价值

原帖第一部分提到了 CLAUDE.md，它源于一个真实的 GitHub 项目 forrestchang/andrej-karpathy-skills。

这个文件提炼了 Andrej Karpathy 对 LLM 编码常见问题的观察，形成四条简短原则：

Think Before Coding
Simplicity First
Surgical Changes
Goal-Driven Execution

翻译成工程语言，大致是：

• 先思考，后编码：先厘清假设，不要带着误解直接动手。
• 简单优先：先选择最小可行实现，不要为了显得聪明而过度抽象。
• 精准修改：只改动任务明确要求的部分，不要顺手重构无关代码。
• 目标驱动执行：将任务改写为可验证的目标，并用测试和检查来闭环收尾。

原帖声称加入这份 CLAUDE.md 后，Claude “违反项目约定”的比例可以从约 40% 降到约 3%。这组数字缺乏公开的基准、测量方法和样本量，适合作为经验参考，而非严肃的性能基准。

但它所指向的问题是真实存在的。这四条原则本身并不新鲜，有经验的工程师都会认同。但问题在于，团队心里知道，不等于 AI Agent 知道。许多 Agent 编码翻车，问题往往不在于某个具体的 API，而在于其工作姿态像一个过度自信的新人：没问清楚就动手、看到相邻代码就顺手“优化”、写完只给解释不给验证。

CLAUDE.md 的作用，正是将这些资深工程师心中的默认约束，显式地写入项目根目录，使其成为 Agent 的运行时上下文。

具体到一个项目中，CLAUDE.md 至少可以包含以下约束：

• 动手前必须先阅读 README、CLAUDE.md、tests/README。
• 禁止修改 infra/、migrations/ 等目录。
• 改动 API 必须补充契约测试。
• PR 描述必须与 Issue 的验收标准对应。
• 不确定的假设必须先提问，不要自行脑补。

这看起来像是给新人写的入职指南。但对 Agent 而言，这就是它每次启动时都能读取的“项目宪法”。说得更直接些，它将团队的工程纪律转化成了 Agent 可消费的运行时配置。

不过，这里需要明确一个边界。CLAUDE.md 只能约束行为倾向，不能替代测试、权限控制和代码评审。它能降低 Agent 胡乱扩展、误改文件、跳过验证的概率，但不能保证每个 PR 都绝对安全。它能把方向盘扶正，但它不是安全带，也不是刹车。

三层闭环，才是真正的工程问题

原帖中可以深入分析的部分，是那位“工程师”描述的三步自动化流程（我们继续对身份持保留态度）。我将其重画为一条更清晰的工作链路：

在这条链路中，.NET 应用不是重点，Claude Code 也不是唯一的变量。真正的重点在于三层工程边界。

第一层：任务准入

很多人设计 Agent 自动化时，第一步就想让它“看到任务就开干”。这往往是事故的开始。

软件任务并不天然适合立即执行。一个 Issue 可能缺少复现步骤、验收标准、影响范围或设计边界，甚至可能只是一个初步的产品想法。人类工程师看到这种 Issue，会先提问澄清。如果 Agent 直接开始编写代码，大概率会自行脑补一堆假设。

因此，一个稳健的系统第一步是做分类和准入判断：

• 这个 Issue 描述是否足够清晰？
• 是否能定位到相关的代码区域？
• 是否有可验证的完成标准？
• 是否需要产品、设计、安全等部门补充信息？
• 是否真的适合由自动化系统处理？

如果判断为“不 ready”，系统就生成一个回复草稿，等待人工确认。这一步看似慢了，实则是在保护后续流程的吞吐量和质量。当 AI 将代码实现的速度压缩到极低时，上游每一个含糊的环节都会成为致命瓶颈。自动化系统的第一道门，就是先筛掉那些当下还不适合编码的任务。

第二层：执行隔离

任务被判定为“ready”后，系统才允许子 Agent（subagent）开始工作。更稳健的做法至少应包含以下约束：

• 每个任务使用独立的 Git 分支或 worktree。
• 明确允许读取和修改的目录范围。
• 执行前必须先读取项目规则文件，如 AGENTS.md、CLAUDE.md、README、测试入口说明等。
• 每次变更都必须能追溯到原始的 Issue 和验收标准。
• 命令执行要有超时、资源预算和日志记录。
• 高风险操作（如执行 Shell 命令、访问网络）需要人工确认。

这就是 Harness（套件/运行时） 的核心工作。模型负责推理和代码生成，Harness 则负责将其接入真实的工程世界：管理上下文、提供工具、维持状态、控制权限、运行测试、处理失败和恢复。

在这个案例中，那个 .NET 应用承担了一部分 Harness 的职责：定时扫描任务、调用 Claude 进行分诊、触发执行、创建分支和 PR、轮询 PR 评论、并将反馈再次交给 Claude 处理。它可能不复杂，但边界清晰。

需要指出的是，原帖未提供代码，我们无法评估其隔离、权限和错误处理的具体实现程度。类似的循环系统在实践中，错误恢复和分支清理往往比想象中更棘手。

第三层：反馈与验收

原帖中有一句话其实比“自动化80%”更重要：代码质量保持一致，因为他会 review everything。

这句话更接近软件工程的本质。在实践 Claude Code 时，有一条经验很深刻：想让 Claude Code 的结果稳定，必须给它一个验证工作的方法。测试命令、浏览器检查、CI 流水线、Reviewer 的评论回流，都属于这种方法。

如果完全取消了人工 Review，系统只是把风险从键盘输入阶段转移到了 PR 合并阶段。更合理的自动化边界应该是：

• Agent 负责：产出候选变更。
• 测试与 CI 负责：提供可重复的质量信号（通过/失败）。
• Reviewer 负责：判断架构合理性、潜在风险、业务语义和长期维护成本。
• 系统负责：将 PR 评论回流给 Agent，驱动下一轮修改。

这也解释了为什么这类系统更像是在改变工程师的时间分布，而非直接“替代工程师”。过去 8 小时可能花在搜索、编码、运行测试、修复格式、响应 Review 上。自动化之后，这些时间被压缩了，但空出来的精力并未用于“休息”，而是更集中地投入到任务拆解、方案决策、风险识别和最终验收上。人的角色没有消失，只是转移了位置。

再看 everything-claude-code：从配置集到运行时优化层

原帖还提到了 affaan-m/everything-claude-code 这个仓库。这个我们在 1 月份曾专门分享过，当时关注点在于如何将个人经验转化为可版本化的团队配置体系。

几个月过去，它已获得 157k star，其定位也进一步演化。

README 将其描述为一个面向 AI Agent Harness 的性能优化系统，支持 Claude Code、Codex、Cursor、OpenCode、Gemini 等工具。仅将其理解为 Prompt 仓库是低估了它。

从目录结构看，它更像一个跨工具的 Agent 工作台与组件库：

• agents/：不同角色的 Agent 定义。
• skills/：可复用的技能模块。
• hooks/：会话、检查、自动化触发点。
• rules/：行为规则。
• mcp-configs/：外部工具（Model Context Protocol）配置。
• .claude、.codex、.cursor、.gemini 等目录：适配不同 Harness 的配置。

值得注意的是，仓库迭代速度很快，README 中不同位置提到的组件数量（Agents、Skills 等）略有差异。这说明组件数量不应成为核心卖点，我们更应关注其设计思想的变化：

• 1 月份时，我们关注它如何将 CLAUDE.md / rules / agents / commands / skills / hooks / MCP 这 7 类构件实现为“配置即代码”。
• 现在，README 更强调 token 优化、记忆持久化、持续学习、验证循环、并行化、子 Agent 编排等。
• 这意味着，它正从一个“配置集合型仓库”，向“跨 Harness 的执行系统与性能优化层”演进。

原帖的提醒是正确的：不要一次性全装、全加载。我更愿意将其视为一个组件货架，根据实际需求按需选取：

要解决的问题	可选择的组件形态	不建议的做法
任务拆分不清	planner / architect 类 agent	让一个全能 Agent 硬拆所有事
代码质量不稳	code-reviewer / tdd-guide / quality gate	只靠主 Agent 自评
安全风险高	security-reviewer / sandbox / allowlist	让 Agent 直接跑高权限命令
长任务断线	memory / session hooks / context rules	一直把所有历史塞进上下文
团队规范难统一	rules / CLAUDE.md / AGENTS.md	靠口头约定或临时提醒

将“配置即代码”和“Issue 处理闭环”放在一起看，关系更清晰：配置即代码让 Agent 知道“怎么工作”；执行闭环则确保它在“对的时间、对的权限、对的验收边界内”工作。 两者结合，才构成有意义的自动化。

这层关系可以概括为下图：

“每15分钟循环”背后的工程清单

原帖将整个系统描述得很轻巧：一个 .NET 应用，每 15 分钟扫描一次 GitLab。这个描述容易让人低估其背后的工程复杂度。如果要在团队中真实落地，至少需要补全以下七类能力：

1. 清晰的“就绪定义”

Issue 必须结构化，以便机器能判断是否“就绪”。这意味着需要任务模板，包含：背景、期望行为、当前行为、复现步骤、影响范围、完成标准、禁止修改的文件/模块等。没有这些，Agent 就只能猜测。

2. 明确的“完成定义”

“实现功能”不是完成。“完成”应对应一组可验证的条件：新增/修改了测试、相关测试通过、代码检查/类型检查/构建通过、PR 描述能映射到 Issue、写明了风险与回滚方案、并获得人工 Reviewer 对语义正确性的确认。这正好对应了 Karpathy 规则中的“目标驱动执行”。

3. 权限控制与沙箱环境

Agent 能写代码，不代表它应该拥有完整权限。更安全的默认设置是：读权限尽量宽，写权限尽量窄；Shell 命令需经过白名单或审批；网络访问按需开启；密钥默认不可见；禁止直接操作生产资源；为每轮任务设置时间和 Token 预算。

4. 健全的测试与 CI 流水线

没有测试，Agent 就没有稳定的反馈信号；没有 CI，Reviewer 会被低级问题淹没，无暇审视架构与风险。许多团队以为自己缺的是更强的模型，实际上缺的是一套可重复的、自动化的验证体系。

5. 可观测性与审计日志

系统必须能回答：Agent 基于哪个 Issue 开始工作？读取和修改了哪些文件？执行了哪些命令？哪一步曾失败？消耗的成本是多少？人在哪个节点进行了批准？缺乏审计追溯能力，自动化很难融入团队协作。

6. 成本与上下文治理

原帖提到了 Claude Code 某些版本的“隐藏 Token 膨胀”问题，并建议降级。这个说法更像社区观察，具体操作应参考官方 Release Notes 和本地日志。但它揭示了一个真问题：长周期自动化必然面临成本与上下文窗口的治理挑战。Token 膨胀不仅是账单问题，还会挤占有效的上下文窗口，稀释 CLAUDE.md 中指令的权重，导致 Agent 在长会话中更容易忽略规则。最小化的治理措施应包括：记录每轮任务的输入/输出 Token 并设置告警、为单任务设置预算上限和最大重试次数、对长循环任务强制进行摘要，避免上下文无限增长。

7. 退出与回滚机制

自动化系统最容易遗漏的就是退出规则。例如：连续失败几次后应停止？PR 评论来回修改多少轮后应交由人工处理？发现测试长期不稳定时如何标记？遇到架构性问题时，是停止实现还是转为提供设计建议？误改文件后如何快速恢复？没有这些规则，Agent 会显得很“勤奋”，但未必可靠。

落地路径：从“只读分诊”开始

对于个人或小团队，不建议一开始就复制“全自动写代码 + 自动 PR + 自动改评论”的完整流程。更稳妥的路线是分三步走：

第一步：只做“只读分诊”

先让系统定期（如每小时）读取 Issue，并输出分析报告：是否就绪、缺少哪些信息、建议补充的问题、可能涉及的代码模块、初步风险等级。这一步不写代码，也不修改任何系统状态，只生成评论草稿。 其收益是能快速暴露团队 Issue 描述的质量问题。

第二步：人工触发执行

当分诊质量稳定后，再允许工程师通过点击按钮等方式，手动触发 Agent 执行某个已就绪的 Issue。执行过程需固定流程：创建独立分支、让 Agent 先生成实现计划、人工确认计划后再开始编码、编码后必须运行测试、PR 描述需自动包含变更范围、验证结果和风险说明。这一步的目标不是无人值守，而是压缩重复劳动，让工程师从一个可 Review 的候选 PR 开始工作。

第三步：接入 PR 评论闭环

最后再处理 PR 评论的自动修改。这里需注意边界：不是所有评论都适合自动处理。

• 适合自动处理：命名调整、测试补充、小范围 Bug 修复、文档和注释修正、Reviewer 明确指出的局部问题。
• 不适合自动处理：架构方向争议、数据模型变更、安全策略调整、涉及多系统的兼容性取舍、Reviewer 也不确定的开放性问题。这一步最能体现“人机协作”的边界：Agent 擅长将明确、具体的反馈转化为代码 Diff，而人类负责判断反馈本身是否合理、成立。

个人自动化 ≠ 团队自动化

原帖描述的场景更偏向个人自动化。个人可以容忍脚本粗糙、日志简略、权限宽松、失败后自己修复。

但团队自动化则完全不同。一旦系统进入团队协作流程，它必须直面以下问题：

• 谁对 Agent 产出的 PR 负责？
• 哪些代码仓库允许自动执行？
• 哪些文件（如关键配置、数据库迁移脚本）永远禁止自动修改？
• 谁能批准执行高风险命令？
• 成本异常由谁跟进处理？
• 线上事故如何追溯到具体的自动化链路？
• 在合规环境下，代码和日志能否发送给外部云模型？

因此，团队在借鉴此类模式时，不能只看“节省了多少人时”。更应该先问：

我们是否具备能力，将 Agent 的每一次动作，都纳入既有的软件工程治理体系（测试、CI、权限、审计、回滚）之中？

这也回到了 AI-First 的核心议题。个人场景中，一个 CLAUDE.md 可能就能显著提升体验；但在团队场景中，它只是一个入口。AI-First 的真正门槛，在于将需求、测试、发布、监控、回滚、审计等能力，改造成 Agent 能读取、能执行、能被约束的系统接口。

回归软件工程主线

作者在文中提到，很多开发者觉得这类自动化太复杂，而“通往全面自动化只隔着三个命令和一个文件”。从某个角度看，确实如此。但从工程现实出发，中间隔着的东西要多得多：

• 清晰、结构化的任务入口。
• 稳定、可版本化的项目规则。
• 可执行、可信赖的自动化测试体系。
• 受控的、最小权限的工具访问。
• 可追溯、可审计的执行日志。
• 支持快速回滚的分支与发布策略。
• 人类深度参与、认真负责的最终验收机制。

这些东西听起来不“酷”，但自动化能否稳定运行，恰恰取决于它们。如果一个团队平时 Issue 写不清、测试不稳定、CI 经常失败、代码边界混乱、Review 流于形式，那么引入再多的 Agent，也只会将混乱放大和加速。

反之，如果这些工程基础已经比较扎实，那么像 Claude Code 这样的工具，确实能高效地“吃掉”大量重复性劳动，让工程师更专注于高价值的判断与设计工作。

最后，回到文章开头那位读者的留言。我同样认同那份担忧：公司不应将核心系统资产直接绑定在某个外部模型上。

更稳健的做法是，让模型处于一个“可替换”的位置：确保输入输出协议清晰、上下文结构化、权限独立可控、日志与成本透明可观测、所有结果必须经过自动化测试和人工 Review 的关卡。这样，即使未来某个模型涨价、服务中断或需要切换供应商，系统中真正有价值的部分——那套沉淀下来的工程实践与接口——依然牢牢掌握在自己手中。

“Claude Code 自动化 80%”这个说法能否成立，目前证据尚不充分。但将工程师的判断、约束和验收机制，拆解为 AI Agent 能够参与、理解的标准化闭环，这件事已经可以开始探索和实践了。即便最终达不到 80% 的自动化率，能稳定、可靠地跑通其中几个关键环节，对于提升工程效能而言，价值已然显著。

---