The full article body is currently published in Chinese. English titles, summaries, and site navigation are available first; full translations can be added article by article.
过去一个月，我用 AI 深度参与了一个 Agent 应用产品的设计和实现。
这个产品的目标是把用户的自然语言目标转化为可执行任务，让系统能够规划、执行、确认、记录结果，并在出现风险时让用户介入。
它不是一个普通聊天助手。
我更希望它成为一个 Task-first 的协作系统：
用户提出目标
-> 系统生成任务草稿
-> 用户确认或编辑
-> 发布执行
-> 观察执行过程
-> 查看结果和证据
-> 失败时恢复、重试或接管一个月之后，我对这个项目的评价更稳定了。
它不是没有价值。
甚至作为 AI 产品和 Agent PM 案例，它很有价值。
但它也暴露了很多失败经验。
最关键的不是“AI 代码写得不够好”，而是我一开始高估了架构、Figma 和大系统设计的价值，低估了产品闭环、状态模型、可恢复性和演示路径的价值。
这篇文章不试图包装成功故事。
它记录的是一次真实失败复盘。
失败一：Figma 投入过重，但没有匹配产品进度
项目早期，我在 Figma 上投入了大量时间。
包括设计稿、治理规则、token、组件骨架、状态页、原型流、handoff 页面，以及后续多轮布局修复。
这些工作不是完全无用。
最后真正对前端实现有帮助的，反而是早期静态视觉稿。
它提供了产品气质、布局密度和界面方向。
但后面为了“规范化”创建的 canonical Figma 组件体系，在状态模型和前端架构还不稳定的时候，变成了一个高成本、低确定性的维护对象。
这不是说 Figma 没用。
问题是它被使用得太早、太重。
早期 AI 产品探索阶段，Figma 更适合承担三个角色：
- 视觉基准：帮助团队理解产品长什么样。
- 交互讨论素材：帮助讨论关键流程。
- 静态验收参考：帮助前端保持体验方向。
它不适合太早成为“实现源”。
尤其在状态模型、交互模型、API 合约还没稳定前，把大量精力放在组件化 Figma 和原型治理上，很容易出现一种错觉：
设计系统很完整，但产品主路径并没有跑通。
经验是：
早期 AI 产品不要急着把 Figma 做成生产级系统。先让产品闭环跑起来，再决定哪些设计资产值得生产化。
失败二：前端开始得太早，缺少状态模型
Agent 产品的前端不是普通表单页面。
它有很多状态：
- 任务是否已规划；
- 任务节点是否 ready；
- 执行是否 pending、running、done、failed；
- 确认是否等待用户；
- 权限是否允许；
- 审计结论是什么；
- 数据是否过期。
我早期的问题是，从静态页面和 mock UI 开始推进前端，而不是先定义状态模型和 ViewModel。
这导致后面出现大量返工：
- Main Page 实现需要不断抽 controller；
- 状态 label 和 tone 需要重新集中映射；
- route / runtime wrapper 后补；
- API adapter 和 reducer contract 后补；
- Audit Page 的入口和 return context 后补。
这些返工不是因为某个组件写错了。
而是因为前端最开始没有回答一个基础问题：
这个页面到底由哪些独立状态维度驱动？
在 Agent 产品里，不能把所有状态压成一个 status。
一个任务可能已经规划完成，但执行还没开始。
执行可能失败，但审计记录仍然可读。
用户可能有查看权限，但没有修改权限。
snapshot 可能过期，但旧内容仍然应该展示。
如果这些维度没有先定义，UI 一定会走向混乱。它会把“权限不足”“执行失败”“数据过期”“证据隐藏”都显示成一种泛泛的错误态。
用户看不懂，代码也很难维护。
后来补上的关键文档包括：
- canonical status model；
- screen state spec；
- event reducer contract；
- API-to-UI mapping；
- frontend architecture plan。
这些文档补完之后，前端才开始有稳定推进的基础。
经验是：
对状态密集型 Agent 产品，前端架构必须先于 UI 实现。页面不是从 Figma 开始，而是从状态模型和交互模型开始。
失败三：没有一开始固化工作流
一开始我知道产品工作流大致应该是：
PRD
-> UX spec
-> Figma / prototype
-> design review
-> frontend architecture
-> API contract / mock data
-> backend integration
-> QA / release但“知道”不等于“执行”。
在 AI 辅助开发中，如果工作流没有写进 repo、写进 agent instruction、写进每个任务的 gate，它很容易被局部任务冲掉。
AI 很擅长完成眼前任务。
用户说“继续下一步”，它会努力推进。
但如果上游依赖缺失，它未必天然会停下来问：
- PRD 是否稳定？
- 状态模型是否存在？
- API 合约是否已定义？
- Figma 是否已经可用于 handoff？
- 这个任务现在真的应该进入实现吗？
结果是，有些工作在缺少前置依赖时就开始了。
短期看进度很快，长期看是在积累返工债。
后来我把工作流固化成 Product Delivery Workflow Gate。
每个任务开始前都必须检查：
- 当前属于哪个阶段；
- 需要哪些上游 artifact；
- 已经找到什么；
- 缺什么；
- 是否允许实现；
- 如果不允许，最小前置工作是什么。
这个机制非常朴素，但对 AI 协作很重要。
它把人的产品判断从“临场提醒”变成了“系统约束”。
经验是：
AI 辅助项目需要显式 workflow gate。否则 AI 会优化局部完成度，而不是全局交付顺序。
失败四：文档重构差点让项目倒退
有一次我对 docs 目录做了重构。
需求没有完全说清楚，目标结构没有先评审，迁移规则也不够严格。
结果重构后的结构不如之前清晰，项目出现倒退风险。
这件事给我的提醒很重。
文档目录不是普通文件夹。
对一个长期 AI 协作项目来说，它是 source of truth 的索引系统。
PRD、ADR、计划、方案、架构、UX、API、release note，彼此之间都有隐含依赖。
AI 如果在没有迁移 map 的情况下大规模移动，很容易破坏这些依赖。
这类重构必须满足几个条件：
- 先给出目标目录树。
- 明确哪些文档是 source of truth。
- 建立迁移表。
- 有备份分支。
- 小批量迁移。
- 迁移后做链接和引用检查。
- 保留 rollback 路径。
好在当时有备份分支，没有造成大事故。
但这个事件说明，AI 并不会天然理解一个项目文档系统的历史语义。
它能整理文件，却未必知道哪些文件承载关键决策。
经验是：
大规模文档重构比代码重构更危险，因为它会移动项目记忆。没有迁移计划，不要让 AI 批量整理 source of truth。
失败五：过早迷恋多 Agent 和总线
项目开始时，我对多 Agent 和 TaskBus 的想象很重。
多个 Agent 协作、任务总线调度、任务树并行推进、系统自动协调，这些概念都很吸引人。
一个月后，我的判断变了。
在 Product 1.0 阶段，最重要的问题不是“如何让多个 Agent 并行”，而是：
- 用户目标能否变成可靠任务；
- 草稿是否会丢；
- 发布是否稳定；
- 执行状态是否能被用户理解；
- 出错后能否恢复；
- 用户能否在关键点确认或补充信息。
这些问题都还没闭环时，多 Agent 并行反而会放大复杂度。
真正困难的不是启动多个 Agent，而是上下文连续性、证据治理、权限边界、失败恢复和用户可理解性。
TaskBus 仍然有价值。
但它更像生命周期事实账本，而不是产品舞台中央的“智能编排大脑”。
它应该记录任务被发布、被 claim、运行、失败、完成。
它不应该一开始就承载复杂调度幻想。
经验是：
Agent 产品早期不要把“多 Agent”当作差异化本身。先证明单条任务路径能稳定完成、可恢复、可解释。
失败六：DFX 被发现得太晚
DFX 指 durability、feedback、recoverability、explainability。
也就是：
- 数据不能丢；
- 用户要知道发生了什么；
- 失败后能恢复；
- 系统行为要可解释。
我一开始没有把它当作产品主路径。
直到 RawTask / DraftTaskTree 没有持久化，导致系统重启后用户上轮未发布的任务丢失，才意识到这是 Product 1.0 级别的问题。
对 Agent 产品来说，DFX 不是后端基础设施优化。
它就是用户体验本身。
用户不会关心你内部有没有漂亮的 task architecture。
他只会关心：
- 我刚刚输入的需求还在吗？
- 我生成的任务草稿还在吗？
- 系统重启后能不能回到上次页面？
- 执行失败后我能不能知道为什么？
- 我能不能重试？
- 我能不能看到产生了哪些文件变化？
如果这些问题没有答案，产品再聪明也不可信。
后来我们才补 RawTask / DraftTaskTree persistence、active authoring state、publish 幂等、result / error summary、message stream bridge、file change summary。
这些工作比很多高级架构更像真正的产品底座。
经验是：
Agent 产品的 1.0 验收标准必须包含“重启后可恢复”。不支持恢复的 Agent 工作台，只是一次性聊天窗口的变体。
失败七：Demo 没有尽早成为最高验收标准
项目中期，我完成了很多内部正确的东西：
- 状态模型；
- 合约；
- reducer；
- mock scenario；
- Figma governance；
- 架构计划。
这些都有价值。
但它们不能替代一个问题：
用户能不能跑完一条真实路径？
对一个作品、产品原型、就业市场展示项目来说，稳定 demo 的价值高于大量内部文档。
因为 demo 是最终压缩后的产品判断：
- 主路径是否能走通；
- 界面是否可信；
- 失败是否可解释；
- 用户是否知道下一步做什么。
这里不是否认文档和测试。
而是排序问题。
早期应该尽快定义一个小闭环：
输入目标
-> 生成任务草稿
-> 用户确认或编辑
-> 发布执行
-> 展示执行状态
-> 展示结果和文件变化
-> 支持失败、重试和恢复只要这个闭环没稳定，其他扩展都应该保持克制。
经验是：
AI 产品开发要尽早拥有一个手动 smoke path。它比抽象完整性更能暴露真实问题。
人的职责不是少了，而是变了
这个月最大的体会是：
AI 可以极大提升产出速度，但它也会放大错误方向的成本。
如果方向正确，AI 可以快速写代码、补测试、整理文档、生成方案。
如果方向错误，它也会非常努力地帮你把错误方向做得更完整。
所以人的职责不是减少，而是改变：
- 人要定义产品闭环；
- 人要判断什么是 source of truth；
- 人要控制工作顺序；
- 人要识别返工风险；
- 人要决定哪些复杂度值得引入；
- 人要及时把经验固化成规则。
我现在更倾向于一种“慢一点”的实现策略：
- 先用最小闭环验证产品。
- 能不做的复杂系统先不做。
- 架构保持可扩展，但实现延迟加载。
- 工作流要硬，功能边界要窄。
- 每次失败都转化为下一次 AI 协作的 guardrail。
这不是反 AI。
恰恰相反，这是更认真地使用 AI。
AI 辅助开发真正有价值的方式，不是让 AI 一口气把宏大系统做出来。
而是让 AI 在明确边界内高效推进，让人把判断力集中在产品闭环、状态模型、用户体验和取舍上。
如果这个月只保留一句话，我会写：
用 AI 做产品，最危险的不是它做得慢，而是它能很快把错误的前提实现得很完整。