外观
为什么有人用 AI 写代码更顺，有人越用越累？
柏林ACS · 2026-08-09 · 读完约需 5 分钟
关于 AI 写代码，程序员分成了旗帜鲜明的两派。
一派说：AI 写的代码很难接手，看着像模像样，一跑问题不少，风格跟项目格格不入，改它的代码比自己写还累。另一派说：效率明显提高，用过就回不去了。
两派用的是同一个模型。如果差异只来自模型能力，体验不该如此两极；至少有一部分差别，出在模型之外。
差别在哪？看一段具体的提问就明白了。
看一段典型的提问就明白了。一个工程师的第一个用法，和很多人一样：
"写一个订单查询接口，支持按状态筛选和分页。"
AI 一口气交出一大段代码：结构漂亮，注释齐全。然后他运行了它。跑不通。再细看：数据库连接用了项目早就淘汰的旧客户端；错误处理是裸抛异常，而项目规范要求统一错误码；变量命名随心所欲，和现有代码风格大相径庭。他花了很久修改这段"免费的"代码，最后比自己写还慢。
后来他把每一次提问做了改造。同一个需求，改造后的 Prompt 长这样：
"项目是 Go + PostgreSQL，使用 sqlc 做数据访问（不要用旧的 xorm 客户端），错误处理必须返回 pkg/errcode 里的统一错误码。
目标：这个接口面向管理后台，QPS 低，可读性和可维护性优先于极致性能。
参照 internal/user/query.go 的结构和命名风格。
先给出接口定义和实现思路，我确认后再写实现。
实现完成后，附上可以直接运行的单元测试。"
五行，各干各的活。第一行是背景和禁区：AI 不知道的事先说清，已经关闭的方向提前关闭——不说，旧客户端和裸抛异常就都在它的候选范围里。第二行是评价标准：什么算好？不说，它就按"看起来像个好答案"的默认标准来。第三行是风格锚点：一份参照文件，胜过一百句"注意代码风格"。第四行把一次开环拆成两段，中间留出人工检查的环节。第五行给结果装上外部判定：能跑测试，就不靠"我觉得对"。
这套问法书里叫四层自检。一次 AI 回答的背后有四层结构：从什么状态起跑（初始化），为了什么而搜（目标），能去哪些地方（空间），怎么走完全程（运行）。回头看改造前的那句提问，四层全部不设防：AI 对项目一无所知，不知道什么算好，没有禁区，一口气跑完没人喊停。模型只是替罪羊。
效果？返工明显少了。
这就是两派的分界线。效率明显提升的人，每次提问都在设计一次搜索：背景给了没有，什么算好说了没有，禁区关了没有，怎么验证想了没有。越用越累的人，提问时什么都不设，拿到结果后在验收环节替 AI 补课——补的还是只有自己才知道的项目信息，自然比自己写还累。
写代码前，可以过一遍这四个问题：
- 背景：它知道技术栈、版本、项目规范吗？还是对这个项目一无所知？
- 标准：我说清"什么算好"了吗？性能优先还是可读性优先，要兼容旧字段吗？
- 禁区：哪些方向已经关闭？淘汰的依赖、禁用的写法，点名了吗？
- 验证：结果拿什么判定？能不能附测试、贴运行结果，而不是"看起来对"？
第 03 篇给过一张四个问题的清单，那是回答已经让你失望之后的事后排查；这张是同一张图的事前用法——问出口之前先自检，而不是拿到烂结果再诊断。
用久了还有一个信号会自己冒出来：每条 Prompt 里都有大段内容在重复——技术栈、规范、约束，每次重新粘贴。重复粘贴的意思是，这些东西不该放在单次提问里，该固化成项目配置，放进仓库根目录的那份 AGENTS.md。那是第 10 篇聊的事：一份好的规范文件长什么样。
四层自检的提问卡和配套的项目配置模板，我整理在公开仓库 acs-templates 里，可以直接拿去用。完整的案例出自《AI认知搜索理论》第十五章——这个工程师后来把这套做法走完了全程：从改造单次提问，到规范进仓库，再到工作流和评审分工，那是书里 AI Coding 一章的内容。
今晚就可以做一件事：翻出最近一次发给 AI 的编码需求，对着那四个问题看一眼——大概率有一到两问是空着的。把空着的补上，再看它交回来的东西。拿不准补没补够，可以把改完的提示词贴进在线诊断工具：它按这四层逐层检查，还你一份修订版。