刚开始用 AI 写代码那段时间,我以为问题出在提示词上。 花了几个月研究 prompt engineering,把需求描述得越来越细,加背景、加限制、加示例。效果是有一点,但始终有个问题绕不开——代码能跑,需求一延伸结构就松了。改一处,另一处崩。再问 AI 怎么修,给的方案和上次矛盾。 后来才想清楚:不是提示词写得不好,是 AI 根本不知道系统应该长什么样。 传统开发的链路是:需求 → 设计 → 代码。AI 辅助开发把中间那段压缩掉了,变成:需求 → AI 猜代码。猜对了是运气,猜歪了就骂"AI 不行"。但缺
Fly个人开发者刚开始用 AI 写代码那段时间,我以为问题出在提示词上。
花了几个月研究 prompt engineering,把需求描述得越来越细,加背景、加限制、加示例。效果是有一点,但始终有个问题绕不开——代码能跑,需求一延伸结构就松了。改一处,另一处崩。再问 AI 怎么修,给的方案和上次矛盾。
后来才想清楚:不是提示词写得不好,是 AI 根本不知道系统应该长什么样。
传统开发的链路是:需求 → 设计 → 代码。AI 辅助开发把中间那段压缩掉了,变成:需求 → AI 猜代码。猜对了是运气,猜歪了就骂"AI 不行"。但缺
SPEC DRIVEN DEVELOPMENT
刚开始用 AI 写代码那段时间,我以为问题出在提示词上。 花了几个月研究 prompt engineering,把需求描述得越来越细,加背景、加限制、加示例。效果是有一点,但始终有个问题绕不开——代码能跑,需求一延伸结构就松了。改一处,另一处崩。再问 AI 怎么修,给的方案和上次矛盾。 后来才想清楚:不是提示词写得不好,是 AI 根本不知道系统应该长什么样。 传统开发的链路是:需求 → 设计 → 代码。AI 辅助开发把中间那段压缩掉了,变成:需求 → AI 猜代码。猜对了是运气,猜歪了就骂"AI 不行"。但缺
const spec = defineRequirements("课程购买漏斗", {
userStories: ["登录后试听", "付费后解锁"],
acceptance: ["优惠券预览", "订单幂等完成"],
}});
const design = createDesign(spec)
.withDataModel("course_orders")
.withTests("checkout + access");
await implement(design);
await verifyWith("pnpm test");WHAT YOU BUILD
把用户故事、边界条件和验收标准写成 AI 能持续引用的规格。
让数据模型、页面流转、权限和支付路径先对齐,再进入实现。
用测试、构建和浏览器检查把每次 AI 生成结果收束到可交付状态。
CURRICULUM