第三章说，决定的时刻从开发时搬到了使用时。那开发者在开发时还干什么？这一章回答这个问题：他们没有失业，但他们手里的工具变了性质——从写规则，变成了立规矩。
写代码是下命令，写提示词是立法
写一行 if-else，你是在给机器下一个必须执行的命令：满足这个条件，就做这件事，没有第二种可能。机器是你的下属，而且是那种绝不自由发挥的下属。
写一段系统提示词（system prompt，开发者预先写给模型的「岗位说明书」，用户看不见但始终在起作用），你做的事情完全不同。你不是在下命令，你是在给一个有能力自由发挥的聪明下属立规矩：「你是我们的客服，语气要客气；退款超过 500 元的，不要自己决定，转人工；不知道的就说不许编。」这些规矩会被遵守——大多数时候。会被创造性地解释——有时。会被绕过去——偶尔。
这就是为什么写提示词的手感更像立法而不是编程：法律条文写得再细，也要靠一个有理解力的执行者去落地，而执行者会在条文没覆盖的地方行使裁量权。于是提示词工程的核心技术，全是立法者的技术：定义角色（你是谁）、划定边界（什么不许做）、给判例（少样本示例，给几个「输入→正确输出」的范例让模型照着学，相当于附在法律后面的指导案例）、写明冲突时的优先级。
大白话：以前开发者是写乐谱的，机器照谱演奏，一个音符都不会错。现在开发者是带乐队的指挥兼经纪人——乐手天才但有个性，你得说清楚要什么风格、什么绝对不能碰，然后接受每场演出都有点不一样。
开发者的新日常：驯化，而不是建造
这种转变落到日常工作上，是三个具体变化：
第一，调试的对象变了。以前代码行为不对，你去找那行写错的代码——错误一定在某个具体的地方。现在行为不对，问题可能根本不在你写的任何一行里，而在模型的「理解」里。你能做的不是修，是引导：换措辞、补示例、加约束。有工程师说得好：以前是外科医生，现在是驯兽师。
第二，最重要的产出物变了。一个 AI 功能真正的「源代码」，越来越不是程序文件，而是那套提示词 + 示例 + 约束的组合。它该进版本管理、该被评审、改动该被追踪——因为它就是行为本身。很多团队已经发现：提示词的一次随手改动，效果等于过去一次代码发布，却常常没有任何评审流程兜底。
第三，品味变得可以复制。传统软件里，「什么叫好的回复」这种判断锁在资深员工的脑子里。现在它可以被写进提示词和评估集，变成团队资产。资深者的经验第一次有了一条低成本的传递通道——这听着是小事，其实是组织知识管理的一次地震（第九章还会回来）。
但别把代码埋了
这里要按住一个流行的夸张：「以后都是自然语言编程，代码不重要了。」不对。准确的图景是分层：
- 确定的事，仍归代码管。钱怎么算、权限怎么查、数据怎么存——这些必须「同样输入同样输出」的地方，if-else 依然是对的工具，而且只有它是对的。
- 模糊的事，归模型管。理解用户在说什么、生成自然语言、处理没预见到的长尾——这些正是第二章说的 if-else 暴政最疼的地方。
- 开发者的手艺，体现在分层的刀法上：哪里必须硬、哪里可以放软、软硬之间怎么接口。这个判断力，比写任何一层本身都更值钱。
所以开发者的角色不是消失了，而是上移了：从规则的撰写者，变成软硬结构的设计师——一部分时间立法（写提示词），一部分时间照旧立法（写代码），但全部时间在做同一件事：决定哪些决定该凝固，哪些决定该留给使用现场。这是全书反复出现的主旋律，请记住它。
立法立完了，下一个问题立刻顶上来：法律要有法院，规矩要有验收。一个行为在使用时才定型、同输入可以不同输出的系统，怎么测？这是第五章的事。