最近 Anthropic 的 Harness 框架在开发者圈子里讨论很多。但读完他们的技术分享后，我意识到一个更深层的问题：我们是否在见证一种通用范式的诞生？
Anthropic 的洞察很扎心：
AI 不是不够聪明，而是没有工作系统。
这像极了职场新人的困境：
问题的核心不是能力，是结构。
仔细拆解 Anthropic 的设计，你会发现一个熟悉的模式：
| 组件 | 功能 | 对应传统工程 |
|---|---|---|
| Initializer | 需求拆解 → 任务清单 | 产品评审 + 技术方案 |
| Coding Agent | 按清单执行 + 自验证 | 开发 + 单元测试 |
| 状态文件 | 实时记录完成度 | 项目管理看板 |
| 测试套件 | 定义"完成"的标准 | 验收标准 (AC) |
这不就是敏捷开发里的 Feature List + Acceptance Criteria 吗？
Anthropic 的实验数据很说明问题：
提升来自哪里？不是模型变强了，而是任务被结构化了。
这让我想到一个可能的推论：
任何需要"多步骤、有状态、可验证"的 AI 任务，都可能需要类似的范式。
不只是写代码：
| 场景 | Feature List 设计 | 验收标准 |
|---|---|---|
| AI 内容运营 | 选题 → 大纲 → 初稿 → 排版 → 发布 | 阅读量、完读率、互动数 |
| AI 数据分析 | 清洗 → 建模 → 可视化 → 解读 | 指标准确性、业务可解释性 |
| AI 客服 | 意图识别 → 知识检索 → 生成回复 → 满意度追踪 | 解决率、用户评分、转人工率 |
| AI 研究助理 | 文献检索 → 信息提取 → 观点整合 → 报告生成 | 引用准确性、逻辑一致性 |
共性：把"黑箱创意"变成"可检查的流程"。
我也在思考：什么情况下它不适用？
可能失效的场景：
换句话说：
Feature List 范式解决的是"可工程化"的问题，不是"不可工程化"的问题。
Anthropic 开源了 Harness 的代码，但更重要的是他们开源了一种思考方式：
AI 项目的管理，正在从"提示工程"转向"系统工程"。
这不是贬低 prompt 的价值，而是承认一个现实：
短期内，我们会看到：
长期看，这个范式是否能完全通用，取决于：
我们能否为"创造性工作"也设计出有意义的验收标准。
这本身是个哲学问题，也是商业问题。
你怎么看？
如果你的工作流被 AI 接管，你会怎么设计 Feature List 和验收标准？
加入讨论
这个”状态文件”的设计让我突然想到——这不就是给AI配了个”工作日记”吗？以前用ChatGPT写长文，每次新开对话都得重新交代背景，烦得很。要是能像Harness这样自动续上进度，确实省心。不过好奇一点：如果任务中途要改需求，这个框架能灵活调整吗，还是得推倒重来？
80%到20%这个对比太扎心了，之前折腾AI写代码深有体会——不是模型不行，是我没给够”脚手架”。不过有个疑问：这套范式对中小团队会不会太重了？感觉更像是大厂AI Infra的玩法。
看到”纯探索性任务不适用”这点突然释然了。之前硬套AI写小说，非要列大纲验收标准，结果写出来跟流水线产品似的。有些活还是得让AI”瞎逛”才有意思。