写给程序员的 Prompt 技巧

  • AI
  • Prompt

网上很多「万能 Prompt」其实泛化过度。程序员日常更需要的是可复用结构：让 AI 知道目标、边界、验收方式和不要做什么。下面是我几个月下来真正在用的写法。

四段式结构（Goal / Context / Constraints / Done）

几乎每个有效 prompt 都能拆成四块：

  • Goal： 一句话说清要达成什么
  • Context： @ 相关文件，或说明技术栈、目录约定
  • Constraints： 不能动的行为、不能加的依赖、代码风格
  • Done： 怎样算完成——命令、页面路径、可见效果

示例（修博客滚动问题）：

Goal: 修复博客列表页和文章页无法纵向滚动的问题。
Context: @src/css/layout/layout.less @src/css/common/subpage.less
         子页面使用 body.subpage，博客页有 main.blog-main / main.post。
Constraints: 不能破坏首页 intro/main 的双屏切换和 overflow 行为。
            最小 diff，只改必要文件。
Done: npm run build 通过；/blog/ 和文章页内容超出视口时可滚动；
      首页切换动画仍正常。

坏 prompt vs 好 prompt

坏： 「优化一下博客页面」

AI 不知道优化什么，可能重写布局、加框架、改配色。

好： 「博客左侧分类点击后应过滤文章，不是滚动定位；增加『全部』分类；宽度保持 920px；请只改 index.pug、blog.less 和必要 JS」

好坏的差别不是礼貌用语，是可验证的指令密度。

三个我常用的模板

1. 加功能

在 [模块] 增加 [功能]。
参考现有 [某页面] 的风格和构建方式。
数据放在 [json 路径]，模板在 [pug 路径]。
不要新增 npm 依赖，不要修改 [排除项]。
完成后运行 npm run build，确认 dist/[路径] 存在。

2. 修 bug

现象：[用户看到什么]
期望：[应该怎样]
已尝试：[可选]
相关文件：@file1 @file2
请先定位根因再改，不要大面积重构。

3. 扩写内容

扩写 [文章 slug] 的正文，保持技术博客语气，中文。
增加 [章节主题]，每节至少 2～3 段具体说明。
可结合本仓库真实技术栈（Gulp/Pug/Less）。
不要改 front matter 以外的模板结构。

要主动写清的「反例」

AI 很爱做「顺手优化」。我会明确禁止：

  • 不要改 dist/ 里手改以外的逻辑（应改 src）
  • 不要加 TypeScript / React / 新测试框架
  • 不要 force push、不要自动 git commit
  • 不要改与任务无关的 config 键名

写进 Constraints，比事后回滚便宜得多。

@ 文件的使用习惯

  • 改样式 → @ 对应 less + 可能受影响的 layout
  • 改构建 → @ gulpfile.js + 一个示例 pug
  • 改内容 → @ _data/*.json + 模板
  • 修导航/路径 → @ nav.pug + 各层级的 base 变量用法

文件给少了，AI 会猜；给多了，它会啰嗦。通常 2～5 个最相关文件刚好。

迭代式 prompt，而不是一次说完

复杂任务不要一次提十个要求。我的节奏：

  1. 先实现最小可用（能 build、能访问）
  2. 浏览器验收，列问题清单
  3. 第二轮只修清单里的项
  4. 第三轮打磨样式/文案

每轮 prompt 都带上一轮哪里不对，AI 修得准得多。

语言选择

我和 AI 对话用中文，代码注释和 commit 看项目习惯（这个仓库英文 commit 也行）。技术术语保留英文（Gulp、Pug、overflow）反而减少歧义。

好 prompt 的标准：别人拿同一份指令，也能判断做没做对。

Prompt 不是玄学。把它当成「给同事的 ticket」来写，质量会稳定很多。