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

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

很多“AI 提效”讨论会默认模型一直可用、价格大致稳定、接口长期兼容。可放到公司系统里，这些都不该被当成默认条件。模型能力可以被调用，但模型本身很难成为一家公司长期可控的资产。供应商会调整策略，价格会变化，API 也可能因为合规、地域、产品线收缩而不可用。如果一套系统把价值全压在某个模型上，风险确实很高。

今天刷到一个已经 287 万浏览的 X 帖，刚好可以带着这个问题往下看。它的标题很直接：“Google engineer automated 80% of his work with Claude Code.”

按原帖说法，一位有 11 年经验的 Google 工程师，用 Claude Code 加一个简单的 dotnet 应用，自动化了 80% 的工作。每天只需要 2 到 3 小时做 review 和测试，其余时间让系统自己跑。

案例真实性说明

我没有找到能独立确认“Google 工程师”身份的一手来源。原帖没有给出姓名、公开主页、代码仓库或当事人说明，也没有给出完整系统代码。"80%"、"28,000 美元被动收入"、"每天只工作 2 到 3 小时"这些数字，更像传播叙事里的钩子，不适合直接当成公司决策依据。原帖还有一处细节更能说明它的叙事风格：“Teams 状态保持在线，鼠标每分钟自动移动一次。”这不是工程经验，这是办公室摸鱼幻想。中文转述稿最后也专门提醒了案例真实性问题。

所以我不打算把它写成传奇故事，更适合把它拆成一个工作流样本。

相比这些还没法核实的数字，我更想先看另一个问题：如果模型不是公司可控资产，那这种 Claude Code 自动化到底还能沉淀什么？

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

任务怎么进入系统，什么状态才可以交给 Agent，Agent 如何拿上下文，代码在哪个分支里执行，测试如何证明没有引入回归，PR 由谁验收，失败之后怎么回滚，成本怎么被看见。

这些东西一旦清楚，换 Claude Code、Codex、Gemini CLI，或者未来某个内部 Agent，都还有迁移空间。反过来，如果只剩几段对话和几个临时脚本，模型一换，很多东西都要重来。

这也是我觉得原帖值得拆开的地方。关键不在“80%”这个数字，它更像是暴露了一条典型的软件工程链路：

Issue 进来，先判断是否 ready；ready 之后开分支实现；实现后发 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 万浏览的帖子，刚好把这三层放进一个最小闭环里。

配置即代码解决的是“Agent 应该怎么工作”；从 Issue 到 PR 的闭环解决的是“Agent 什么时候可以开始工作、做到哪里必须停下来、结果由谁验收”。

这个案例刚好提供了一个更小的剖面：一个人想把 Claude Code 从“帮我写一段代码”推进到“帮我持续处理一批任务”，中间到底缺什么。

核心结论

• 昨天留言区的问题：模型不是公司可沉淀的资产，围绕某个模型写死系统，会遇到供应、成本和合规风险。

• 原帖里的“Google 工程师”、80% 自动化、28,000 美元被动收入，证据链不足。这里先把它当成一个自动化工作流素材，不把数字当事实结论。

• 能留下来的，是任务入口、项目规则、测试体系、权限、日志、回滚、成本预算和验收机制这些模型外的软件工程接口。

• 更值得关注的是 Issue -> 分诊 -> 分支开发 -> PR -> Review -> 再修改 这条闭环，“少工作”只是原帖的叙事外壳。

• 原帖说“通往全面自动化只隔着三个命令和一个文件”。工程上看，中间隔着的是任务入口、项目规则、测试体系、权限、日志、回滚和验收机制。

• CLAUDE.md 的价值在于把项目级行为约束写成 Agent 每次都能读到的工程接口，不能只把它看成提示词玄学。

• everything-claude-code 这类仓库更像组件货架和配置基线，优先学结构和边界，不要全量安装。

• 自动化的关键门槛有三层：任务准入、执行隔离、反馈验收。少任何一层，都会从“自动化”滑向“自动制造技术债”。

• 配置即代码是第一步，执行闭环是第二步，团队治理是第三步。三层都到位，自动化才稳。

• 个人自动化案例不能直接外推到团队自动化。个人可以容忍脚本粗糙、权限大、失败自己修；团队不行。

• 个人可以从只读分诊开始试，不要一上来就让 Agent 自动合并代码。

• 团队要复制这类模式，先补测试、CI、权限、日志、回滚、成本预算和审计，而不是先堆 Agent 数量。

CLAUDE.md 先别神化

原帖第一部分讲的是 CLAUDE.md。 它提到有人把 Andrej Karpathy 对 LLM 写代码常见问题的观察，整理成一个项目级规则文件。这个仓库是真实存在的，叫 forrestchang/andrej-karpathy-skills。这个文件的四个原则很短：

• Think Before Coding

• Simplicity First

• Surgical Changes

• Goal-Driven Execution

翻成工程语言，大概是：

• 先讲清假设，不要带着误解直接开写。

• 先选最小实现，不要为了显得聪明过度抽象。

• 只改任务需要的地方，不要顺手重构一片。

• 把任务改写成可验证目标，用测试和检查闭环收尾。

原帖声称加上这份 CLAUDE.md 后，Claude “违反项目约定”的比例可从约 40% 降到约 3%。这组数字没有公开基准、测量方法和样本量，适合当经验说法，不适合当严肃 benchmark。但它指向的问题是真实的。这四条原则本身不新，做过几年工程的人大概都会点头。但问题是，团队心里知道不等于 Agent 知道。很多 Agent 写代码翻车，问题通常没卡在某个 API 上，而是工作姿态像一个过度自信的新人：没问清楚就动手，看到相邻代码顺手优化，写完之后只给解释，不给验证。

CLAUDE.md 的作用，是把这些资深工程师心里的默认约束，显式写到项目根目录里。落到实际操作上，一个项目的 CLAUDE.md 至少可以包含这些约束：

• 先读 README、CLAUDE.md、tests/README，再动手。

• 不允许修改 infra/、migrations/ 目录。

• 改动 API 必须补 contract test。

• PR 描述必须映射到 Issue 验收标准。

• 不确定的假设先问，不要自己补。

这些看起来像是给新人写的入职须知。但对 Agent 来说，它就是运行时上下文。 说直接点，它就是把团队工程纪律变成了 Agent 每次启动时都能读到的运行时上下文。之前聊 Codex 仓库的时候我们也反复说过类似的话：能长期复用的是沉淀在仓库里的工程经验，单句 prompt 很难长期承重。

不过这里有一个边界：CLAUDE.md 只能约束行为倾向，不能替代测试、权限和评审。它能减少 Agent 胡乱扩展、乱改文件、跳过验证的概率，但不能证明每个 PR 都安全。 它能把方向盘扶正，但它不是安全带，也不是刹车。

三层闭环，才是工程问题

原帖里可以拆的部分，是那位“工程师”的三步自动化。这里继续加引号，是因为身份没有被独立确认。我把它重画成一条链路：

graph TD
	A[Gitlab Issue<br>每15分钟扫描] --> B{准入分诊<br>是否ready}
	B -->|不ready| C[补充信息草稿<br>等待人确认]
	B -->|ready| D[Agent执行<br>新分支开发]
	D --> E[创建PR<br>跑测试和检查]
	E --> F[人类Review<br>验收质量与风险]
	F --> G[评论回流<br>继续修改]
	G --> E

这条链路里，dotnet 不是重点，Claude Code 也不是唯一变量。重点是三层边界。

第一层：任务准入

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

软件任务并不天然适合执行。一个 Issue 可能缺复现步骤，缺验收标准，缺影响范围，缺设计边界，甚至只是一个产品想法。

人类工程师看到这种 Issue，会先问问题。Agent 如果直接开写，大概率会自己补假设。

所以这个系统第一步做的是分类：

• 这个 Issue 是否足够清楚？

• 是否能定位到代码区域？

• 是否有可验证的完成标准？

• 是否需要产品、设计、安全或数据侧补信息？

• 是否适合自动化处理？

不 ready，就生成回复草稿，等人确认。 这一步看似慢，实际是在保护后面的吞吐量。

讨论 AI-First 时，有一个判断一直绕不开：当 AI 把实现速度压到很低，下游每一个含糊环节都会变成瓶颈。 这里也一样。 自动化系统的第一道门，是先筛掉那些现在还不适合写代码的任务。

第二层：执行隔离

ready 之后，系统才让 subagent 开始工作。

更稳的做法应该至少包含这些约束：

• 每个任务使用独立分支或 worktree。

• 明确允许读取和修改的目录范围。

• 写入前先读项目规则，如 AGENTS.md、CLAUDE.md、README、测试入口。

• 每次变更都要能追溯到 Issue 和验收标准。

• 命令执行要有超时、预算和日志。

• 高风险操作需要人工确认。

这就是 Harness 的工作。

模型负责推理和生成，Harness 负责把它接进真实工程世界：上下文、工具、状态、权限、测试、恢复。

之前拆 Coding Agent 6 个组件的时候，有一个感觉很明确：真实可用的 Coding Agent，外面一定有一层系统。同样的模型，放进聊天框和放进工程运行时，表现差距不小。

这个案例里，dotnet 应用承担的就是一部分 Harness 职责：

• 定时扫描任务。

• 调 Claude 做分诊。

• 触发执行。

• 创建分支和 PR。

• 轮询 PR 评论。

• 把反馈再次交给 Claude。

它不复杂，但边界清楚。这里我有一个没想清楚的地方：原帖没有给出代码，我们看不到它的隔离、权限和错误处理到底做到了什么程度。 我自己也试过类似的循环，坦白说很多时候错误恢复和分支清理比想象中麻烦得多。所以这里只讨论这类系统应该长什么样，不能替原案例背书。

第三层：反馈验收

原帖里有一句话其实很重要：代码质量保持一致，因为他会 review everything。 这句话比“自动化 80%”更接近软件工程。

整理 Claude Code 实战习惯时，有一条我印象很深：想让 Claude Code 结果稳定，要给它一个验证工作的方法。测试命令、浏览器检查、CI、reviewer 评论回流，都算。 如果人不 review，系统只是把风险从键盘输入阶段搬到了 PR 阶段。

更合理的自动化边界应该是：

• Agent 负责产出候选变更。

• 测试和 CI 负责给出可重复信号。

• Reviewer 负责判断架构、风险、语义和长期维护成本。

• PR 评论再回流给 Agent，形成下一轮修改。

这也解释了为什么这个系统更像是在改变工程师时间分布，而不是直接“替代工程师”。

过去 8 小时可能花在搜索、改代码、跑测试、修格式、响应 review 上。自动化之后，这些时间被压缩了，但空出来的部分不是用来休息的。任务切分、方案判断、风险识别、最终验收，这些事反而变得更重了。

人的角色没有消失，只是换了个位置。

几个月后再看 everything-claude-code 仓库

原帖还提到了 affaan-m/everything-claude-code。 这个仓库我们 1 月份已经专门分享过。当时更关心的是：怎么把 Claude Code 的个人经验，从聊天记录、口头约定、临时 prompt，升级成可版本化的团队配置体系。 隔了几个月再看，它的定位又往前走了一步。已经157k star。README 里把它描述成面向 AI agent harness 的性能优化系统，覆盖 Claude Code、Codex、Cursor、OpenCode、Gemini 等工具。 把它理解成普通 prompt 仓库，会低估它。

从目录看，它更像一个跨工具的 Agent 工作台：

• agents/：不同角色的 agent。

• skills/：可复用技能。

• hooks/：会话、检查、自动化触发点。

• rules/：行为规则。

• mcp-configs/：外部工具配置。

• .claude、.codex、.cursor、.gemini 等目录：适配不同 Harness。

不过这里也要补一个细节。 README 不同位置的组件数并不完全一致：v1.10.0 更新说明里写的是公开面同步到 38 个 agents、156 个 skills、72 个 legacy command shims；Quick Start 后面又写安装后可以访问 48 个 agents、183 个 skills、79 个 legacy command shims。 这说明它还在高速迭代。引用这类数字时，不要把组件数当成核心卖点。

我更关心的是它的方向变化：

• 1 月时候我们看它，重点是 CLAUDE.md / rules / agents / commands / skills / hooks / MCP 这 7 个构件如何配置即代码。

• 现在 README 更强调 token optimization、memory persistence、continuous learning、verification loops、parallelization、subagent orchestration。

• 也就是说，它正在从“配置集合型仓库”，往“跨 Harness 的执行系统和性能优化层”走。

这里我会先看它把哪些能力拆成了文件，而不是先看装了多少东西。 原帖里有一句提醒是对的：不要一次性全装、全加载。 原因也简单。 很多人看到这种仓库，第一反应是全部复制进项目。结果上下文变重，规则互相打架，Agent 反而更不稳定。我更愿意把它当成一个组件货架：

要解决的问题 可以选择的组件形态 不建议的做法 任务拆分不清 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 靠口头约定临时提醒

围绕 Anthropic Harness 写到“从补短板到删 dead weight”时，有一个判断我现在还是认同：模型越来越强之后，Harness 不该只会往上堆东西。每次新增 agent、skill、hook，都值得问一句：它到底在承重，还是只是让系统更重？

把配置即代码和这个 Issue 闭环放在一起看，关系会更清楚： 配置即代码是第一步，让 Agent 知道团队怎么工作。 执行闭环是第二步，让它在对的时间、对的权限、对的验收边界里干活。 两层都到位，才谈得上自动化。

graph TD
	A[配置即代码<br>CLAUDE.md/rules/skills/hooks] --> C[执行闭环<br>Issue分诊/分支开发/PR回流]
	B[人类验收<br>方向、风险和合并责任] --> C
	C --> D[团队治理<br>权限/审计/成本/回滚]
	B --> D

“15 分钟循环”背后的工程账

原帖把整个系统说得很轻：一个 dotnet 应用，每 15 分钟扫一次 GitLab。 这个描述容易让人低估它背后的工程账。 如果真要在团队里落地，至少要补七类能力。

1. Definition of Ready

Issue 必须能被机器判断是否 ready。 这意味着任务模板要结构化：

• 背景是什么？

• 期望行为是什么？

• 当前行为是什么？

• 如何复现？

• 影响范围在哪里？

• 完成标准是什么？

• 哪些文件或模块不能碰？

没有这些字段，Agent 就只能猜。

2. Definition of Done

“实现功能”不是完成。 完成应该对应一组可验证条件：

• 新增或修改测试。

• 相关测试通过。

• lint / typecheck / build 通过。

• PR 描述能映射到 Issue。

• 风险和回滚方案写清楚。

• 人类 reviewer 确认语义正确。

这正好对应 Karpathy 规则里的 Goal-Driven Execution：不要只告诉 Agent 做什么，要给它成功标准。

3. 权限与沙箱

Agent 能写代码，不代表它应该拥有完整权限。 更稳的默认值是：

• 读权限尽量宽，写权限尽量窄。

• shell 命令走 allowlist 或审批。

• 网络访问按任务开关。

• secret 默认不可见。

• 生产资源不可直接操作。

• 每轮任务有时间和 token 预算。

这部分如果缺失，自动化程度越高，事故半径越大。

4. 测试和 CI

没有测试，Agent 就没有稳定反馈；没有 CI，reviewer 会被低级问题淹没，根本腾不出精力看架构和风险。 我自己观察下来，很多团队觉得自己缺的是更强模型，实际缺的是可重复的验证信号。模型可以参与补测试，但测试体系本身要先成为项目资产。

5. 可观测与审计

Agent 自动改代码之后，系统至少要能回答这些问题：

• 它基于哪个 Issue 开始工作？

• 读了哪些文件？

• 改了哪些文件？

• 跑了哪些命令？

• 哪一步失败过？

• 成本消耗是多少？

• 人在哪个节点批准过？

没有审计，自动化就很难进入团队协作。

6. 成本与上下文治理

作者还提到 Claude Code 某些版本存在隐藏 token 膨胀问题，并建议降级到某个版本。 这个说法目前更像社区观测，不适合直接写成操作建议。版本、计费、上下文策略都变化很快，真要处理，应该回到官方 release、npm 包、账单和本地日志做交叉验证。 但它提醒了一个真实问题：长任务自动化一定会遇到成本和上下文治理。

原文还提到了一个更值得注意的逻辑链：隐藏的 token 膨胀不只是账单问题，它会占用 Claude 实际的上下文窗口，稀释 CLAUDE.md 里的指令权重，导致长会话中 Agent 更容易忽略规则。这个逻辑链本身是合理的，但具体的版本差异和数字，建议回到官方 release notes 和本地日志交叉验证。 一旦系统每 15 分钟循环一次，token 预算、上下文裁剪、日志保留、失败重试，都不再是小问题。

最小的工程 guardrail 至少包含三项：

• 每轮任务记录 input / output token，异常时自动报警。

• 单任务设置预算上限和最大重试次数。

• 长循环任务强制摘要，不要无限续上下文。

之前拆 Claude Code 长任务 Runtime 的时候，有一个设计让我印象很深：它不会把所有历史一直塞进窗口，而是分层处理，什么该落盘，什么该摘要，什么该回灌，什么该直接丢掉。15 分钟循环系统面对的是同一类问题。

7. 退出和回滚

自动化系统最容易漏掉的是退出机制。比如：

• 连续失败几次后停止？

• PR 评论来回改几轮后交给人？

• 发现测试长期不稳定时如何标记？

• 碰到架构性问题时是否停止实现，转为设计建议？

• 误改文件后怎么恢复？

没有这些规则，Agent 会显得很勤奋，但不一定可靠。

落地顺序：从只读分诊开始

如果是个人或小团队，我不会一上来复制“全自动写代码 + 自动 PR + 自动改评论”。

更稳的路线是三步。

第一步，只做只读分诊

先让系统每隔一段时间读取 Issue，然后输出：

• 是否 ready。

• 缺哪些信息。

• 建议补充的问题。

• 可能涉及的模块。

• 初步风险等级。

这一步不写代码，也不改 GitLab，只生成草稿。 它的收益很快能看出来：团队会发现自己的 Issue 质量到底能不能支撑自动化。 如果连分诊都经常错，后面执行一定更危险。

第二步，人工触发执行

当分诊质量稳定后，再允许人点一个按钮触发 Agent 执行。 执行时要固定几件事：

• 创建独立分支。

• 先生成计划。

• 人确认计划后再写代码。

• 写完必须跑测试。

• PR 描述自动写出变更范围、验证结果和风险。

这一步的目标并非完全无人值守，重点是把重复劳动压下去。更贴近工程现实的收益通常是：工程师不再从空白编辑器开始，而是从一个可 review 的候选 PR 开始。

第三步，接入 PR 评论闭环

最后再处理 PR 评论。 这里要注意，不是所有评论都适合自动修改。 可以让 Agent 自动处理：

• 命名调整。

• 测试补充。

• 小范围 bugfix。

• 文档和注释修正。

• reviewer 明确指出的局部问题。

不适合自动处理：

• 架构方向争议。

• 数据模型变更。

• 安全策略调整。

• 涉及多个系统的兼容性取舍。

• reviewer 自己也不确定的开放问题。

这一步最容易体现“人机协作”的边界：Agent 适合把明确反馈转成 diff，人负责判断反馈本身是否成立。

个人自动化和团队自动化，不是一回事

原帖里的场景更像个人自动化。 个人自动化可以容忍很多东西：脚本粗糙一点、日志少一点、权限大一点、失败了自己修。 团队自动化不行。 一旦系统进入团队协作，它至少要面对这些问题：

• 谁对 Agent 产出的 PR 负责？

• 哪些仓库允许自动执行？

• 哪些文件永远不能自动改？

• 谁能批准高风险命令？

• 成本异常由谁处理？

• 线上事故如何追溯到自动化链路？

• 合规环境下，代码和日志能不能发送给外部模型？

所以团队复制这类模式时，不能只看“省了多少小时”。 更应该先问：我们有没有能力把 Agent 产生的每一次动作，都纳入已有的软件工程治理里？

这也回到了 AI-First 那个问题。 AI-First 的门槛，落在需求、测试、发布、监控、回滚、审计这些能力上：它们要被改造成 Agent 能读、能跑、能被约束的系统。 个人场景里，一个 CLAUDE.md 可能就能显著改善体验。团队场景里，它只是入口。 Anthropic 自己大概也意识到了这一点。他们把 Agent 运行底座托管出来做 Managed Agents，背后其实在承认：当 Agent 从个人工具进入团队流程，难点会转向运行、权限、审计、成本、恢复这些系统能力。 AI-First 的讨论最后也会落到同一个地方。

回到软件工程这条线

作者说，很多开发者达不到这个水平，主要是觉得它太复杂。他还说，通往全面自动化只隔着三个命令和一个文件。 确实是的。但从工程上看，中间隔着的东西要多得多。 中间至少隔着这些东西：

• 清楚的任务入口。

• 稳定的项目规则。

• 可执行的测试体系。

• 受控的工具权限。

• 能追溯的执行日志。

• 可回滚的分支策略。

• 人类仍然认真 review 的验收机制。

这些东西不算酷，但自动化能不能稳定跑起来，往往就取决于它们。 如果一个团队平时 Issue 写不清，测试不稳定，CI 经常红，代码边界混乱，review 只看格式，那再多 Agent 也只是把混乱放大。反过来，如果这些工程基础已经比较扎实，Claude Code 这类工具确实会把很多重复劳动吃掉。

最后回到开头那个留言。 我也有这个担心: 公司不该把一套系统的核心资产，直接押在某个模型上。 更稳妥的做法，是让模型处在可替换的位置：输入输出协议清楚，上下文结构化，权限独立，日志和成本可观测，结果必须经过测试和 review。这样哪怕某个模型涨价、不可用，或者团队需要切换供应商，系统里最有价值的部分仍然留在自己手里。

Claude Code 自动化 80% 这个说法能不能成立，我目前觉得证据还不够。但把工程师的判断、约束和验收，拆成 Agent 能参与的闭环，这件事已经可以开始做了。我自己也在试，有些环节比想象中顺，有些比想象中难。特别是任务准入那一步，Issue 质量不够的时候，后面全是连锁反应。 哪怕最后做不到 80%，能稳定跑通几个环节，已经很有价值。

参考资料

• Noisy 原帖：https://x.com/noisyb0y1/status/2043609541477044439 • Noisy 推文：https://x.com/noisyb0y1/status/2044077615791641070 • Karpathy-Inspired Claude Code Guidelines：https://github.com/forrestchang/andrej-karpathy-skills • Everything Claude Code：https://github.com/affaan-m/everything-claude-code