使用 AI 写代码过程中必须保留的批判性思考

开发工具栈

Anthropic 最近一篇讲上下文工程新规则的博客里明确提到，他们为 Claude 5 代模型砍掉了 Claude Code 超过八成的 system prompt。官方承认模型变强后，过去那一大段指令反而稀释了注意力。

轻量化是大家共同的方向，Claude Code、Codex、Pi 挑顺手的用即可。工具不是重点，下面简单推荐几个我日常在用的。

一是 Matt Pocock 的 matt skills 这套 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，这是第一道人工门控。

当然这套链路并不轻。单文件小改动、边界清楚、验证成本低时，直接用 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 可能已经替他做了一堆糟糕的取舍，而他自己并不知道哪些取舍发生过。

讲 AI 时代的软件工程基本功，里面有个观点我很认同。不懂软件基础的人 Vibe Coding 可以完成开发，但麻烦在于 Agent 可能已经帮他做了一堆糟糕的取舍，而他自己都不知道哪些取舍发生过。接口延迟、可用性、一致性、成本，这些 trade-off 即使有 AI 后也不会消失，而人的判断会越来越重要。

AI Coding 迭代速度太快，这次分享的内容可能三个月后就会过时。但有几件事我确定不会过时。一件是对系统的理解，选延迟还是选系统成本，要简单还是要可扩展，一致性优先还是可用性优先，这些判断大模型它只能给选项，给不了你最优结论。另一件是工程直觉，哪段代码可疑，哪个需求有坑，哪条 Review 意见是噪音，这也是 AI 替代不了的。

思考

这段分享展现了一套前沿且高度工程化的 AI-Native 开发实践（从 Spec-Driven 到 Worktree 并发，再到对抗性评审），它对“瓶颈转移到需求对齐与 Review”的判断很敏锐；但推敲其底层逻辑与落地现实，仍有几个值得深思的盲点与取舍：

其一是“工具轻量化”与“流程重型化”的认知错位：原文推崇砍掉八成 system prompt 的轻量趋势，却又设计了一套极严密的重型流水线。

• 工具极简 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、垂直切片等经典软件工程纪律，这正是它能跑通的原因；但它的危险在于过早优化了“高并发生产代码”的能力，却低估了多模型仲裁与集成带来的认知税。更务实的演进是保留苏格拉底式对齐与 Spec 规范，简化多 Agent 对抗，把省下的精力投向自动化回归测试与可观测性。

这套 SOP 的核心价值在于高度尊崇经典软件工程纪律（TDD、清晰 Spec、垂直切片） ，这也是为什么它能跑通的原因——它用传统的高标准工程规范驯服了 AI 的随意性。

然而，它的危险之处在于过早优化了“高并发生产代码”的能力，却低估了“多模型仲裁与集成”带来的认知税 。在实际工程落地中，更实用的演进路径是：保留苏格拉底式对齐与 Spec 规范，但简化多 Agent 对抗机制，将节省出来的精力投向强化自动化回归测试与可观测性体系上。