衡量 AI 编程生产力，应该看一个可验证结果用了多少时间和成本，而不是生成了多少代码。最有用的一组指标包括结果周期、一次验收率、返工、漏出缺陷、人工注意力和单个已验证结果成本。它们能区分真正改善交付与单纯增加活动量。
先定义结果单位
选择用户或运营人员能识别的单位，例如完成一次新手引导、解决一个生产故障、上线一个集成，或验证一个产品假设。提示词数量、提交次数和生成代码行数只是活动计数，它们可以不断上升，而产品没有任何进展。
每项工作开始前先写完成条件。如果结果无法观察或测试，应先改善任务定义，再评估智能体。
跟踪六项实用指标
- 结果周期： 从接受任务到验证完成的总耗时。
- 一次验收率： 无需修复循环就通过约定检查的结果比例。
- 返工率： 修正、撤销或缩小智能体产出所花的时间。
- 漏出缺陷： 结果被接受或上线后才发现的问题。
- 人工注意力： 主动审查、提示、诊断与协调时间。
- 单个已验证结果成本： 模型、工具、基础设施与审查成本除以被接受的结果数。
不要把所有指标压成一个漂亮分数。周期更短但漏出缺陷更多，是需要调查的权衡，不是自动胜利。
建立一个小而可比的基线
选择一种重复出现的任务，在引入智能体工作流前后各观察几次，并尽量保持难度与完成规则相近。独立开发者通常没有足够样本获得统计确定性，因此这些数字应作为决策证据，而不是通用行业基准。
OpenAI 的 GPT-5.6 效率报告展示了如何在受控任务中同时比较质量、token 与延迟。你自己的项目也需要更小规模的同类纪律。DORA 的 AI 辅助开发报告则说明，AI 的效果会受到交付实践影响，并非“用了工具”就必然改善。
把验证计入工作成本
智能体产出只有在可以被信任后才算有效生产力。测试、真实运行检查、外部投递确认和修复时间，都应计入周期与成本。排除验证，只会奖励快速草稿，并把成本藏到审查阶段。
可以按AI 生成代码上线前验证指南建立可重复证据。
按失败模式复盘趋势
每周或每完成一小批任务，回答：
- 哪类任务最容易一次通过？
- 哪类任务的审查时间超过实现时间？
- 哪些缺失上下文反复制造返工？
- 哪些检查能在上线前抓住问题？
- 哪些场景中手工处理仍然更快或风险更低？
只在证据指向的地方调整工作流。更好的任务说明、更窄的工具权限、更清晰的仓库指令或更小的任务范围，可能比换模型更有效。
SoloMap 把计划步骤、完成条件、运行证据和交接留在项目中，因此你可以比较“原本承诺什么”和“最终验证了什么”，而不必拿代码量做代理指标。SoloMap 方法论把有证据的完成作为进度单位，独立开发者的构建—销售—学习—改进循环则把交付指标连接到产品学习。
常见问题
代码行数完全没有用吗？
它可以描述审查规模，却不能说明价值或正确性。可用于安排审查，不应成为主要生产力指标。
至少需要多少任务才能比较工作流？
可以先观察五到十个相似结果，并明确结论只是方向性的。在做高成本或不可逆决策前，应扩大样本。
等待智能体运行的时间要计入周期吗？
端到端周期应计入，同时单独记录人工主动时间。这样才能看出总耗时是否增加，而你的专注时间是否减少。