开发工具栈
Anthropic 最近发了一篇博客讲上下文工程的新规则，里面明确说他们为 Claude 5 代模型砍掉了 Claude Code 超过八成的 system prompt。官方承认模型强了之后，之前的大段指令反而稀释注意力。
轻量化是共同的方向，Claude Code、Codex、Pi 挑顺手的用就好。工具不是重点，下面简单推荐几个我日常在用的工具。
一是 matt skills，Matt Pocock 的 Skill 集合，他应该是全世界最会写 Skill 的男人，我日常用的五个如下。
Skill | 作用 |
grill-me | 苏格拉底式追问，把模糊想法问清楚 |
grill-with-docs | grill 加强版，逐问对齐的同时落 ADR 和术语表 |
to-spec | 把对齐结果写成 spec 文档 |
to-tickets | 把 spec 拆成垂直切片的 tickets，带依赖 DAG |
implement | subagent 拉取 ticket 实现，内部执行 TDD 和 code-review，自己修到过审 |
二是 ponytail ，用于消除 AI Slop。LLM 写代码经常爱写一堆没意义的内容。防御性的空检查，永远不会有第二个实现的 interface，给常量再包一层 private 常量，注释里写满过程性标注等等。这些内容单看也许没问题，但长期下来无论是人维护还是 AI 维护都是负担。ponytail 的作用就是卡控这些内容，这个逻辑要不要存在、代码库里有没有现成的、标准库能不能干、能不能一行写完，都答不上来才许写新代码。使用后 diff 明显变短，而短 diff 是好 review 的前提。
三是 subagent 加 worktree。并发跑多个任务时用 git worktree 做隔离，各改各的避免冲突，worktree 是 git 的通用概念，哪个 Harness 都能用；在 Claude Code 和 Codex 里 subagent 是原生的。而 Pi 秉持 Less is More 的思路，原生并不提供 subagent，原因是作者任务使用 tmux 等原语即可实现 subagent 的并行、避免上下文腐化等功能。我日常使用
Herdr ，可以理解为 AI 时代的 tmux，比 subagent 更轻，还能让 Pi 直接操纵里面的 Claude Code、Codex 这些进程。
三、日常 Coding SOP
先用 grill-me / grill-with-docs 对齐上下文。这个阶段和 AI 一轮一轮脑暴对齐需求的边界、约束等。对齐后用 to-spec 产出 spec 文档，人工 Review 一遍，这是第一道人工门控。spec 过了用 to-tickets 垂直切片拆分任务，每个 ticket 可独立交付执行。接着派 subagent 跑 implement，一个 ticket 一个 subagent，worktree 隔离并发执行，执行内部走 tdd + code-review。全部完成后做 PR 级的 review，最后人工 CR 把关。
当然这套链路也不算轻，如果是单文件的局部小改，边界清楚，验证成本低，直接 Main Agent 对齐快速改动即可。但轻流程有两条底线，改动前依然需要先出简单方案等人授权，改完必须跑测试。流程可以分级，纪律不能分级。
四、人工 Review 是新的瓶颈
Anthropic 前阵子发了一篇 AI-native SDLC 的 playbook ，里面有个结论是代码生成已经快到飞起，软件开发的瓶颈移到了 Coding 的左右两侧，出方案、Review、部署上线这些环节还在以人的速度跑。
我的体验是，当前软件开发的并发上限卡在人的 Review 带宽上。
Claude Code、Codex 随便开，worktree 随便建，这些层面的并发几乎免费，但一个人同时处理四个 Session 就比较勉强了，如果处理八条一定会有遗漏。所以未来 Harness 的竞争点，我认为会往压缩人工 Review 成本的方向走。
Ensemble Review 是我现在压缩 Review 成本的手段，原理是让不同厂商的模型交叉审查同一段代码。每个模型都有系统性盲区，GPT 看不出的问题 DeepSeek 可能一眼就看到了，单一模型自审等于让考生自己改卷子。我的配置是四路对抗 Reviewer，GPT、GLM、DeepSeek、Kimi 分别拉起一个 subagent 同时使用干净上下文，跑同一个审查 skill。
但大模型 Review 再多，最后还是得让人来判断，四路结论摆在一起，这个判断仍然是人的活。
五、软件工程思维仍关键
吴恩达最近有篇 文章
讲 AI 时代的软件工程基本功，里面有个观点我很认同。不懂软件基础的人 Vibe Coding 可以完成开发，但麻烦在于 Agent 可能已经帮他做了一堆糟糕的取舍，而他自己都不知道哪些取舍发生过。接口延迟、可用性、一致性、成本，这些 trade-off 即使有 AI 后也不会消失，而人的判断会越来越重要。
AI Coding 迭代速度太快，这次分享的内容可能三个月后就会过时。但有几件事我确定不会过时。一件是对系统的理解，选延迟还是选系统成本，要简单还是要可扩展，一致性优先还是可用性优先，这些判断大模型它只能给选项，给不了你最优结论。另一件是工程直觉，哪段代码可疑，哪个需求有坑，哪条 Review 意见是噪音，这也是 AI 替代不了的。
思考
这段分享展现了一套非常前沿且高度工程化的 AI-Native 开发实践（从 Spec-Driven 到 Worktree 并发，再到对抗性评审），其对“瓶颈转移到需求对齐与 Review”的判断极其敏锐。但在推敲其底层逻辑、边际成本与落地现实时，存在几个值得深思的工程盲点与权衡取舍：
1. “工具轻量化”与“流程重型化”的认知错位
工具极简 vs. 流程繁琐： 原文一方面推崇“大模型变强后砍掉 80% System Prompt”的轻量化趋势，另一方面却设计了一套极端严密的重型流水线（
grill→spec→tickets→TDD→worktree 并发→4路对抗 Review）。真实效能开销： 这套仪式感十足的流水线适合中大型业务架构演进，但在多数日常需求交付中，维护 DAG Ticket 拆分、处理 Worktree 分支合并冲突（Git merge conflicts）以及环境配置的时间，往往已经超过了实际编码时间。当开发门槛从“写代码”变成“管理由 5 个阶段和多个 subagent 构成的庞大流水线”，这本质上是用流程的超载替代了编码的超载。
2. “Ensemble Review”（四路对抗）看似降本，实则推高认知负荷
噪音放大与注意力稀释： 让 GPT、DeepSeek、GLM、Kimi 四路并发评审同一段代码，表面上消除了盲区，但 LLM Reviewer 极易产出大量“可改可不改”的伪代码异味（Code Smell）、主观的代码风格争执或过度防御性建议。
审卷人变成了法官： 原文承认“四路结论摆在一起，最后还是得让人判断”。这意味着人类工程师不仅要 Review 原始代码 Diff，还要去 Review 四个 AI 产生的上百行审查意见并做判决（仲裁）。在多数工程实践中，阅读并过滤 4 份充满假阳性（False Positives）的评审报告，耗费的心智带宽往往远高于直接扫一眼短 Diff。
3. 对“AI Slop（代码垃圾）”的防御存在代际滞后
过度依赖外挂门禁： 工具（如
ponytail）强制拦截防御性空指针、无用接口或冗余封装，确实能缩短 Diff。但这种卡控规则本质上是用静态规则或启发式 Prompt 去修剪模型的坏习惯。推理模型的反噬： 随着具有长思维链（Reasoning/Thinking）的大模型普及，模型在自主规划时本就具备精简冗余的能力。如果在 Harness 层叠加层层严厉拦截，极易引发模型“过度纠错”，出现代码为了强行精简而牺牲可读性、甚至导致边界用例被砍掉的风险。
4. “并发上限卡在人类 Review”的解法存在根本性局限
并发的假象： 作者提到“一个人同时处理 4 个 Session 比较勉强，8 个一定遗漏”。但这不仅是带宽问题，而是架构全局一致性（System Coherence）的瓦解。
局部最优与全局次优： 8 个独立的 subagent 在各自的 worktree 里切片交付 ticket，即使各自都通过了 TDD 和本地代码审查，集成在一起时依然容易出现隐式依赖冲突、重复造轮子以及设计范式漂移。
真正的破局方向： 压缩 Review 成本的终局很可能不是让多模型来“挑刺”，而是让验证左移并由确定性基础设施兜底——例如更完备的端到端集成测试、属性测试（Property-based Testing）、金丝雀灰度以及契约测试（Contract Testing）。用确定性的测试流水线拦截问题，永远比让概率性的模型互评更节省人类注意力。
核心总结
这套 SOP 的核心价值在于高度尊崇经典软件工程纪律（TDD、清晰 Spec、垂直切片），这也是为什么它能跑通的原因——它用传统的高标准工程规范驯服了 AI 的随意性。
然而，它的危险之处在于过早优化了“高并发生产代码”的能力，却低估了“多模型仲裁与集成”带来的认知税。在实际工程落地中，更实用的演进路径是：保留苏格拉底式对齐与 Spec 规范，但简化多 Agent 对抗机制，将节省出来的精力投向强化自动化回归测试与可观测性体系上。
浙公网安备 33010602011771号