为一个 RSS 阅读器开发保存功能，需求是把文章存成 Markdown 或 PDF。功能做完之后，模型多提了一句：用户可能不知道已经保存过了，要不要把这个按钮变成“已完成”的标记。需求没有变，交付多了一层对使用者处境的考虑。这类时刻把一个老问题重新摆到了桌面上：和模型协作时，究竟需要规定到什么程度。
指令执行的尽头
以前与模型协作的常见形态是逐步规定：先做什么、再做什么、格式如何、哪些不许碰。规定得越细，越容易暴露两个问题。一是写全所有步骤几乎不可能，总有没有料到的分支；二是提需求的人自己也可能不懂某些环节，一条外行的字面指令，反而会把执行带偏。
最近的使用体验里出现了变化：模型不再盲从字面要求，按需求做完，还会从全局考虑这个设计最终要服务于什么，必要时指出“不能这么做”。过去那种讨好式的逐步执行，常让协作显得笨拙；现在它更像在理解意图之后给出方案。
对齐取代了步骤清单
反映到日常用法上，写提示词的重心变了。过去是引导、约定、严格限制每一步；现在主要在做对齐——说清楚想做什么、为什么做、做到什么程度算好，至于具体怎么干，不再逐一规定。
这不意味着提示词没有用了，而是两类信息的位置发生了变化。描述“怎么做”的部分在退化，描述“做什么”和“怎么算好”的部分更重要。省下来规定步骤的时间，最好花在把目标本身讲清楚上。
模型变强，需求反而更容易露馅
对齐目标的前提，是目标本身成立。同一时期的观察里有一类典型困境：要求太多、对要做的东西缺乏概念，订阅额度一周耗尽，做出来的东西还不符合要求。模型不会替使用者发明一个清晰的目标；表达混乱时，混乱同样会被执行放大。
专业判断因此没有贬值。一位有开发经验的用户描述过另一条路线：用更快的模型先出一个六七十分的结果，再靠自己的专业判断反复调整到九十五分，总耗时反而更短。判断力和验收标准，仍然长在懂业务的人身上——模型越强，“好”的定义越是由人来给。
边界仍然由人画
把判断交给模型，也要把判断的范围交代清楚。把一整套 Obsidian 插件搬进另一个运行环境时，交代方式是：判断哪些功能与笔记无关，自己决定去掉。模型完成了裁剪和迁移，但“笔记相关”这个范围本身，来自对业务的理解——委托出去的是执行中的判断，画边界的前提仍然是人对事情的理解。
步骤会过时，规则不会
另一个信号来自沉淀下来的流程。有使用者发现，把为旧模型准备的视频制作 Skill 用到新模型上，效果反而下降。这个观察值得记下现象，而不急于推断原因——模型内部为什么受影响，外界无法验证。它至少提醒一件事：为模型当时的能力缺口写的操作步骤，可能随着模型变强变成约束。
沉淀指令时值得区分两类内容。一类是“怎么做”的操作步骤，它们依附于模型当时的能力水平，会过时，需要定期清理；另一类是稳定的业务规则——口径、约束、格式、验收标准，无论模型多强都值得写明。把后者误当成前者一起删掉，和把前者当成长期规则供着，是相反方向的同一种错。
从规定步骤到对齐目标，不是管得更少，而是管的地方变了。仍待回答的问题是，哪些约束值得显式写下来——这没有通用答案，只能按项目逐个判断。