很多人卡在同一个地方：脑子里有一套后台该长什么样，却写不出一行代码，把需求丢给 AI 之后又不知道该信哪一版。这篇不教语法，只给一套能照着走的流程——从把功能拆成对话能接住的小块，到每轮怎么描述、怎么检查、什么时候该换工具。看完至少能判断：AI 给的这版是能用的，还是看着像但不能上线的。
很多人卡在同一个地方：脑子里有一套后台该长什么样，却写不出一行代码，把需求丢给 AI 之后又不知道该信哪一版。这篇不教语法，只给一套能照着走的流程——从把功能拆成对话能接住的小块，到每轮怎么描述、怎么检查、什么时候该换工具。
看完至少能判断：AI 给的这版是能用的，还是看着像但不能上线的。全程你不用翻文档、不用装环境，靠对话推进，但每一步都要有你自己的判断，模型只是帮你把话变成代码的那个人。
先弄清对话式编程能干什么、不能干什么
它的本质是你出判断、模型出代码。你负责说清「要什么」和「什么算合格」，代码细节交给它。你不需要懂语法，但必须懂你自己的业务——哪张表该有什么字段、谁能删谁不能删，这些模型猜不出来，只有你知道。
适合的场景是结构清楚、逻辑不绕的中后台：列表、表单、增删改查、简单权限、导入导出。这类东西模式固定，模型见得多，出错也好查。
- 适合：客户管理、订单查看、内容审核、简单统计看板这类以表格和表单为主的后台
- 不适合：涉及支付结算、复杂并发、已有系统深度改造，这些地方必须有人能读懂代码兜底
- 判断标准很简单——你能用一句话说清这块业务规则，它就大概率能写；说不清就先别动手
- 拿不准的边界问自己：如果它写错了，我能不能只看界面就发现？能发现就敢试，不能发现就先找人
动手前先把后台拆成能对话的小块
按「页面 + 动作」拆，不要按「整个系统」提需求，一次只让模型碰一块。比如「客户列表页 + 新增客户」是一块，「订单详情页 + 改状态」是另一块。块越小，它改错的范围越小，你也越容易看出问题。
先定三张清单：有哪几张数据表、每张表有哪些字段、谁能看到哪张表。这三样定不下来，后面会反复返工。别怕改，改清单比改代码便宜得多。
- 列数据表把所有要存的东西写成表名，比如客户表、订单表、账号表，先只写名字不写字段。
- 每张表填字段每个字段写清名字和类型，比如「姓名，一段文字」「金额，数字」，不用管技术术语。
- 标权限在每张表旁边写一句话：谁能看、谁能改、谁能删，说不清的先空着。
- 写验收标准每个动作写一句人话，比如「新增客户后能在列表第一行看到，刷新还在」，后面照着验收。
- 念一遍把三张清单从头念一遍，念不通说明你还没想清楚，这时候改需求比改代码便宜得多。
每一轮对话怎么说，模型才不跑偏
用「现在有什么 / 要加什么 / 改完长什么样」三段式描述，别只说「优化一下」。模型最怕模糊指令，它只能自己猜，猜错了你还得回头找原因。
一次只提一到两个改动点。混着提会让它改错地方，还可能悄悄动其他已经好的文件——这是很多非技术用户踩过的坑，改完一看别的地方又坏了。
- 给它明确的边界：别动已经验收过的部分、不要引入新的依赖、不确定就先问
- 改完让它自己说明改了哪些文件、为什么这么改，你看不懂技术词也要看它有没有说清改了什么
- 同一处连着改两三次还不对，说明需求没说清，退回上一节重新拆，别硬耗
- 每次改动前留个记录，比如把当前版本复制一份，坏了能退回去
| 别说 | 改成说 |
|---|---|
| 优化一下客户页面 | 客户列表加一列「最近联系时间」，默认显示空 |
| 加个权限 | 销售只能看到自己名下的客户，管理员能看到全部 |
| 数据不太对 | 我新增了一个客户叫张三，刷新后列表里没有他，只有之前的两条 |
边做边看：先把能跑通的路径走一遍
每完成一块就真点一遍，顺序是新增 → 列表 → 编辑 → 删除 → 刷新后还在。顺序别乱，因为后一步会依赖前一步的数据，倒着点会踩出一堆假问题。
重点看三类问题：数据是不是真的存进去了、权限有没有漏、删除这类危险动作有没有二次确认。这三类问题在界面上不一定看得出来，得靠你手动试。
- 发现不对不要自己猜原因，把「我点了什么、期望什么、实际什么」原样贴回去让它定位
- 它给的回复你看不懂也要看完，至少看它有没有承认问题、有没有说改哪里
- 一次只验一个问题，别连着点七八下再一起说，那样说不清是哪一步坏的
- 验完一块就在清单上划掉一块，剩下的心里有数
验收清单：什么样才算能上线
功能面：每条主流程走通，空数据、超长文本、重复提交这类边界各试一次。空数据就是列表什么都没有时页面别崩，超长文本就是名字写两百个字时别把页面撑坏，重复提交就是连点两下新增别出来两条。
数据面：确认数据存在哪、备份怎么恢复、上线后谁能改，这三件问不出来就先用着别给客户看。备份这件事很多人做完就忘了，等数据丢了才想起来。
| 检查面 | 要问的问题 | 答不上来怎么办 |
|---|---|---|
| 功能 | 每条主流程我点通了吗，边界情况试了吗 | 没试就先自己点一遍，别急着上线 |
| 数据 | 数据存哪，怎么备份，怎么恢复 | 先不上线，找懂的人问清再说 |
| 安全 | 登录、权限怎么做的，接口 Key 放在哪 | 让它明确回答，不能写在前端页面上 |
| 维护 | 以后改文案、加字段找谁，有没有说明 | 让它写一份简单说明留着，别只存脑子里 |
什么时候该停下来找人接手
出现「能跑但不知道为什么会跑」的模块，先标记出来，别在上面继续叠功能。这类模块往往是后面出大问题的地方，叠得越多越难拆。
涉及真实用户的钱、身份信息、对外接口时，找懂开发的人过一遍，这笔钱比返工便宜。这不是说对话式编程不行，是说这类地方的容错空间太小，错了代价太大。
- 后台开始要接第三方系统、跑定时任务、做复杂报表时，对话式推进的效率会明显下降
- 判断信号：你发现问题越来越难用一句话说清，就是该换方式的节点
- 找人接手前把三张清单和验收记录整理好，交接能省一半时间
- 别把「找人看一遍」理解成推倒重来，多数情况只是补几处关键地方
工具和环境怎么选，别在这上面卡住
先用现成的对话式编程工具跑通一个最小后台，再决定要不要换成更工程化的方案。很多人一开始就在选工具上耗掉好几天，其实先动手比先选对更重要，做一轮就知道自己缺什么。
不同工具的额度口径不一样，同一件事消耗差很多。具体各家怎么算、当时是什么政策，去站内 /coding-plans 核对当时的数字，别按别人说的老信息下单。
- 不确定哪类工具适合自己，到 /ai-nav/category/ai-coding 翻一遍分类，按「要不要自己部署」先筛一轮
- 关心响应速度和稳定性，可以到 /tools/speed-test 跑一遍再决定，别只信宣传
- 别一上来就买贵的，用一个小后台跑完一轮完整流程再决定续不续费
- 想看别人怎么评这些工具，去 /rankings 看当时的榜单，排名会变，别当成定论
常见问题
完全不懂代码，做出来的后台敢给客户或同事用吗？
内部小工具、自己团队用的后台，走通验收清单基本可以用；一旦涉及外部用户、付款、身份信息，就必须找人过一遍代码。判断分界线不是「能不能跑」，而是「出了问题谁负责、损失多大」。
对话里要不要一次把整个后台需求讲完？
不要。一次讲完的结果是模型生成一堆你无法判断对错的东西，改起来更痛苦。按页面和动作拆成小块，每块单独验收再往下走，返工成本低很多，你也能随时停下来。
它写的代码我看不懂，怎么知道没埋坑？
看不了代码就看行为：危险操作有没有二次确认、数据刷新后还在不在、接口密钥有没有出现在页面里。看不懂的部分让它用一句话解释「这段是干什么的」，解释不清就先不打勾。
改了几轮越改越乱怎么办？
先把当前能用的一版固定下来，别在上面继续加。把需求重新拆一遍，只挑一块最关键的从头重做。反复在乱版本上打补丁，是这类项目最常见的失败方式。
这样做出来的东西能一直用下去吗？
短期够用，长期要看维护成本。字段加多了、规则变复杂了，改一次的时间会明显变长。到那个节点，把需求文档整理出来交给开发人员接手，比继续硬改划算。
