从提示词到工作流：构建可持续迭代的 AI 开发体系

提示词解决一次沟通，工作流解决持续交付。当 AI 进入真实团队，决定效果的不是某一句神奇指令，而是上下文、规范、工具和反馈能否形成闭环。

Prompt 只是起点

一次 Prompt 可以让模型生成页面，但无法保证下次仍遵守路由、国际化、权限和发布规则。可持续体系要把隐含要求显式化：把稳定知识写成文档，把任务过程写成 Skill，把外部能力接成 MCP，把完成标准写成 Spec。

一个可复用的任务模板

目标：新增一个门户报表页面
上下文：读取当前菜单树、路由规范和 UI 组件文档
约束：URL 必须包含完整目录层级，不修改默认布局
执行：先输出方案，再修改文件，最后运行 check/test/build
交付：变更摘要、检查结果、截图和未解决风险

反馈让系统变好

每次任务结束后，把“哪里出错、为什么出错、如何避免”沉淀回文档或 Skill。成功案例也应保留最小示例，避免团队只记住最终答案却忘记判断过程。

一个完整的前端 AI 工作流

1. 提出目标：说明用户和问题
2. 读取上下文：项目规则、页面、组件和现有测试
3. 输出方案：列出假设、替代方案和风险
4. 写入 Spec：固定状态、约束和验收标准
5. 执行实现：小步修改，随时可回退
6. 自动验证：类型、测试、Lint、构建和产物
7. 人工确认：决定是否合并、发布或继续迭代
8. 沉淀反馈：更新文档、Skill 和测试案例

开发者可以把这套流程封装成项目命令或任务模板：

1
2
3

pnpm ai:plan -- "新增一个带权限的报表页面"
pnpm ai:verify
pnpm ai:summary

命令背后不一定需要复杂的 AI 服务，关键是固定输入、输出和验证证据。未来切换模型或工具时，团队仍然沿用同一套任务协议。

如何避免工作流变成负担

低风险小改动可以直接执行，跨模块任务才要求完整 Spec；只读查询不需要审批，写文件需要确认，发布和删除必须人工确认。工作流应根据风险分级，否则开发者会为了绕过流程而放弃使用。

适合沉淀的团队资产

最值得沉淀的不是某个模型的提示词，而是页面验收清单、组件使用规则、错误案例、发布回滚步骤、Review 关注点和真实任务样例。这些内容才会随着团队发展持续产生价值。

人仍然是系统的一部分

权限边界、产品取舍、隐私、安全和发布决定不能被自动化掩盖。好的 AI 工作流会明确哪些步骤自动执行，哪些步骤必须确认，哪些结果必须由领域专家复核。

小结

从 Prompt 到 Workflow，是从“让 AI 帮我写一段代码”走向“让 AI 在团队规则中完成一项可验证工作”。这也是 AI 真正融入前端工程的关键一步。