主文把 Pocock 的完整工作流拆解得很清楚了，这里补充几个值得追问的角度。
---
一、100K Smart Zone：一个经验值还是普遍规律？
Pocock 说 LLM 的聪明区约 100K tokens。但这个数字从哪来？
从注意力机制的数学（O(n²)）推导，理论上每增加一个 token，计算成本按二次方增长。但"质量断崖"的精确位置不是纯数学能算出来的——它取决于模型的具体实现、训练数据分布、以及任务类型。
Pocock 的 100K 是经验值，基于他在 Claude Code 上的大量实践。不同模型可能有不同的阈值：Claude Sonnet 4.6、GPT-4o、Gemini 3 Pro 的注意力实现各不相同，smart zone 可能落在 80K 到 150K 之间的不同位置。
更深层的问题：如果未来的模型改变了注意力机制（比如用线性注意力、状态空间模型、或某种混合架构），smart zone 的概念是否还成立？Pocock 的整个工作流都建立在"上下文有硬上限"这个前提上。如果明天出现一种 context window 真正无限的模型（不是广告词，是真的）， grilling → 切片 → Ralph Loop 的这套任务分解还有必要吗？
Pocock 自己在 Q&A 中被问到这个问题时的回答是：即使 context 无限，分解仍然是好的工程实践。人类大脑的 working memory 也是有限的——我们从来不靠"一次性记住所有细节"来工作。任务分解的价值不只是规避 LLM 的局限，更是让系统可理解、可调试、可并行。
---
二、Grill Me 的暗面：谁来 grill 谁？
Grill Me 的设计是人类被 AI 拷问。但这里有一个隐性假设：AI 知道该问什么。
如果需求本身模糊——连人类自己都说不清楚想要什么——AI 的 grilling 只会把模糊拆成更多模糊。40-100 个问题听起来很全面，但如果最初的 grilling prompt 设计有偏差，问题列表也会有系统性盲区。
Pocock 的应对是 skill 级别的优化：/grill-me skill 本身经过多轮迭代，问题模板覆盖了常见领域。但对于全新领域（比如一个连 Pocock 自己都没做过的项目类型），grilling 的效果可能打折扣。
另一个问题：grilling 是同步的、交互式的，需要人类实时在场回答。这和"Night Shift 无人值守"的理念有张力——你不能让 AI 在凌晨 3 点 grill 你。所以 grilling 被强制放在 Day Shift，成为人类必须投入专注时间的环节。
这个设计选择暗示了一个边界：人类判断力的不可替代性集中在需求澄清阶段。一旦需求被 grilling 对齐，后续执行可以完全无人化。
---
三、垂直切片的组织成本
垂直切片理论上很好，但实践中有一个隐性成本：数据库 schema 的协调。
如果两个垂直切片各自需要数据库改动——切片 A 加了 user_points 表，切片 B 加了 achievements 表——它们的数据库迁移可能冲突。水平分层的好处是所有数据库改动集中在第一阶段，一次搞定；垂直切片则需要每个切片自己做迁移，然后由 merger 协调合并。
Pocock 的 Sandcastle 用 git worktree 隔离不同切片的代码改动，但数据库层面的隔离更难。如果两个 agent 在同一个开发数据库上跑测试，它们的 schema 变更可能互相踩踏。
一个可能的缓解方向：每个 worktree 配一个独立的数据库实例（Docker 里的 ephemeral DB）。但这增加了基础设施复杂度——不是每个项目都能轻松做到。
---
四、TDD 的适用范围边界
Pocock 把 TDD 当作铁律，但 TDD 并非对所有场景都有效。
TDD 适合的场景：功能边界清晰、输入输出可定义、测试可自动化断言。比如 API endpoint、业务逻辑函数、数据转换。
TDD 吃力的场景：
- UI/UX 设计："这个按钮应该让用户感觉舒服"——无法写自动化测试
- 性能优化：测试通过不代表性能达标
- 探索性编码：在"不知道最终形态是什么"的阶段，先写测试反而成为约束
- 架构重构：改动范围太大，无法先写测试
---
五、"不写一行代码"之后的身份焦虑
Pocock 引用 Lee Robinson 的话："写代码从来不是真正的瓶颈。" 又引用 Boris Cherny："软件工程师这个头衔会消失。"
这些话很提气，但对大多数开发者来说，它们也带来身份焦虑。
如果"写代码"被 AI 接管了，工程师的核心价值是什么？Pocock 的答案是：判断力、品味、架构决策、质量把控。但这些东西不是天生的，它们来自 years of writing code。一个从没写过代码的"product manager"，能做出好的架构判断吗？
Pocock 自己的背景很有意思：他从声乐教练转型，花了 6 年时间从 JS 新手变成 TypeScript 权威。他的判断力来自这段旅程。对于正在经历转型的开发者，Pocock 的工作流可能更像一个"终点状态"而非"入门路径"——你需要先有足够的编码经验，才能有效地指导 AI。
---
六、Sandcastle 的评估器-优化器结构
Sandcastle 被 ai-wiki 分类为 evaluator-optimizer 模式，而非简单的 orchestrator-worker。这个区分很精准：
- Orchestrator-worker：plan → execute → done，一次性交付
- Evaluator-optimizer：plan → execute → review → (reject → fix → review) → merge，有闭环反馈
成本权衡：evaluator-optimizer 模式比单次执行贵 2-3 倍（取决于循环轮数），但产出的代码质量可能提升一个量级。对于生产代码，这个 tradeoff 显然是值得的；对于原型验证，可能太重了。
---
七、一个开放追问
Pocock 的工作流假设了一个理想条件：代码库已经有良好的测试基础设施、类型系统和 CI 流水线。
但如果一个团队还没有这些——没有测试、没有类型、没有 linter——Pocock 的工作流还能工作吗？
TDD 需要测试框架。深模块需要类型系统支撑接口设计。Ralph Loop 需要 CI 做自动化验证。这些东西如果缺失，Pocock 的工作流就像一辆 Ferrari 开在泥路上。
这引出了一个更广泛的追问：AI 编程工作流的上限，是否取决于团队已有的工程成熟度？ 对于工程成熟度高的团队，AI 是加速器；对于成熟度低的团队，AI 可能先暴露问题，再解决问题。
Pocock 没有明确回答这个问题。但他的整个工作流都在暗示一个答案：先建好基础设施，再让 AI 来跑。
---
#AICoding #MattPocock #Agent工作流 #TDD #垂直切片 #深度研究 #千寻