Prompt进阶：9个月总结的核心工作流，让AI进入工程流程

Prompt进阶9个月总结的核心工作流让AI进入工程流程而不是让它裸奔。问题你在帮AI还是在添乱大多数人用AI写代码的姿势输入需求让它生成报错了修一修再生成循环往复结果看似高效实际埋坑。一个忽略现有缓存层的函数一个没考虑ORM规范的数据迁移一个跟别处重复的API接口。这类错误安静、隐蔽三个月后让整个系统雪崩。核心心法需求先工件化执行先加护栏一句话总结让需求先变成工件让代码只在护栏里改。❌ 帮我写个用户认证模块 ✅ 先出方案我审核通过后再写代码三步工作流经过9个月验证第一步让AI先读懂帮我理解这个系统 - 深入阅读src/目录下的代码 - 理解架构和数据流 - 复杂度、依赖关系、最容易出错的地方 把分析写进research.md我确认后再下一步关键用深入、“细节”、复杂度这类词告诉AI别走马观花。第二步写计划反复标注修改基于对系统的理解帮我出开发计划 1. 要做什么 2. 改动哪些文件 3. 风险点在哪 4. 待实现的功能清单 写成plan.md然后在编辑器里直接往plan.md加注释两个字的也有“不可选”一段话的也有解释某个业务约束或者纠正架构方向最后把文档扔回给AI我加了一些注释按注释更新plan.md先不要写代码。第三步一口气实现完全部实现。 完成一项就在plan.md里标记。 不到所有任务完成不要停。 持续运行类型检查。进阶OpenSpec工作流来自真实项目验证对于真实生产项目推荐用OpenSpec管理变更生命周期/opsx:propose → 需求拆解产出proposal/design/tasks ↓ /opsx:apply → 执行代码改动 ↓ /opsx:verify → 核对实现是否和change工件对齐 ↓ /opsx:archive → 归档保持上下文干净为什么这套流程重要阶段问题解决propose边界定义不清先拆成工件人审applyAI自己扩需求只做tasks.md范围内的事verify不知道改了什么检查是否和工件对齐archive上下文越来越乱归档保持干净最佳实践把实现、评审、验证彻底拆开最危险的的不是AI写不出来而是它在没有边界的情况下乱改它不知道项目里的历史隐性约定它把实现、评审、验证混在一起它改完了代码却没有把风险说清楚它碰到了SQL、配置、脚本这类高风险区域却没有硬护栏应该拆成不同职责职责做什么/opsx:verify检查实现是否和OpenSpec对齐prepare-review整理这次改了什么方便人reviewspring-architecture-review检查Spring分层有没有乱sql-risk-review检查SQL、批量更新的风险reviewer只读视角的代码审查硬护栏permissions hooks规则写进文档只是软约束真正能拦住危险动作的是权限和hook。高风险目录默认禁止修改src/main/resources/application*.ymlsrc/main/resources/db/sql/deploy/secrets/权限配置示例~/.claude/settings.json{permissions:{deny:[sql/*,deploy/*,src/main/resources/application-prod.yml]}}Hook自动检查{hooks:{BeforeWrite:[{matcher:*.sql,command:echo SQL变更需要人工审核}]}}隐性约定要单独文档化对真实业务项目来说最危险的通常不是显式规则而是那些大家都知道但没人写下来的东西。最佳实践把所有容易导致改完能跑、联调出错的口头约定单独沉淀到docs/implicit-contracts.md。例如 - 单元详情接口里前端依赖contentResponse做回显 - status null 和 status 0 在历史语义上并不等价