Slack Code 可以让你和团队一起看：
AI 的计划。
Code Diff。
Live Preview。
再决定要不要接受修改。
但如果一开始只跟 Agent 说：
「帮我把这里改好。」
后面即使所有人都看得到，
还是可能发生一个问题：
大家心里想的「改好」，根本不是同一件事。
所以今天只学一个动作。
在 Agent 开始改以前，
先写三格：
现在。
要变成。
不能动。
第一格：现在怎样？
先把目前问题说清楚。
例如不要写：
手机版按钮不好看。
改成：
手机版首页第一屏的「免费试用」按钮目前太靠近页面底部，用户需要往下滑才能看到。
这一格是在定义：
起点。
因为如果连现在发生什么都没有说清楚，
AI 就会开始自己判断：
是哪一个按钮？
哪个页面？
哪个尺寸？
什么叫不好看？
第二格：要变成怎样？
接着不要只说：
「改善一下。」
要告诉 AI：
最后你希望看到什么。
例如：
手机版首页打开后，不卷动画面就能看到完整的免费试用按钮。
这就是：
验收条件。
修改完成后，
不用争论：
「感觉好像有比较好。」
直接看：
有没有做到？
第三格：不能动什么？
这一格反而最容易被忘记。
例如你的真正需求只有：
手机版 CTA 往上。
但是 Agent 为了做到这件事，
可能顺便修改：
桌面版间距。
字体。
导览列。
其他 Button Style。
甚至共用 CSS。
所以第三格可以写：
桌面版版型、按钮文字、品牌字体与其他页面不得修改。
这是在告诉 Agent：
成功不是改得愈多愈好。
成功是：
把指定问题修掉，
其他正常的东西留下来。
三格合起来就完成了
最简单格式就是：
现在
目前发生什么问题？
要变成
修改完成后，用户应该看到什么？
不能动
哪些原本正常的功能、页面或数据必须保持不变？
例如：
现在： 手机版首页第一屏看不到完整的免费试用按钮。
要变成： iPhone 尺寸打开首页后，不卷动就能看到完整 CTA。
不能动： 桌面版、CTA 文字、导览列、其他页面与登录流程都不要修改。
先根据这三个条件提出计划。
如果需要改动「不能动」区域才能完成，先停下来告诉我，不要自行扩大范围。
这已经是一个很好用的 Slack Code 任务起点。
为什么 Slack Code 特别需要这种写法？
因为 Slack Code 的重点不是：
一个人和 Agent 私下工作。
它把：
产品。
工程。
设计。
其他相关同事
拉进同一个 Code Channel。
Slack 官方设计就是让大家可以在同一空间：
规划。
Prompt Agent。
查看变更。
查看 Preview。
一起 Review。
所以这时候最怕的不是：
没有人看到。
而是：
每个人看到的目标不同。
例如产品经理想的是 A
产品经理说：
手机版 CTA 要明显一点。
他心里可能只是希望：
按钮提高 40 像素。
设计师想的是 B
设计师看到后可能理解成：
整个 Hero Section 重新排版。
AI 又可能理解成 C
Agent 为了让 CTA 更明显，
可能：
换颜色。
加大字。
改 Margin。
重排版面。
三个人都没有错。
问题只是：
「明显一点」没有明确验收条件。
所以不要等 Code Diff 出来才第一次讨论需求
Code Diff 告诉你的事情是：
AI 改了什么。
它不能替你回答：
这些修改是不是原本真正想要的。
Live Preview 告诉你：
现在画面变成什么样子。
它同样不能替你回答：
这是不是正确的产品需求。
因此最便宜的修正时间，
永远是在：
Agent 还没开始大量修改以前。
「现在」这一格要尽量可观察
不要写：
网站很难用。
因为这太大。
可以改成：
手机版结帐页的折扣码字段位于付款按钮下方，测试用户容易找不到。
或者：
深色模式下，主要 CTA 文字与背景对比不足。
或者：
商品页在 390px 宽度时，价格与加入购物车按钮重叠。
这些都有一个特色：
看得到。
AI 改完后，
也比较容易：
验证。
「要变成」不要写技术做法，先写结果
例如不要第一句就要求：
把 padding 改成 16px。
因为你真正要解决的问题可能是：
按钮被遮住。
如果 AI 发现：
16px 还是被遮住，
它反而会被你锁在错误解法里。
比较好的写法是：
修改完成后，在指定手机尺寸下，按钮不得被遮挡，而且第一屏可以完整看到。
你定义：
结果。
Agent 再提出：
怎么做到。
什么时候才指定技术做法？
如果那个技术本身就是限制，
再写。
例如：
不准改 API。
不准改 Database Schema。
不增加新的 Dependency。
必须保留现有 Design Token。
这些就很适合放到：
不能动。
因为它们不是偏好。
而是：
边界。
「不能动」尤其适合保护共用组件
AI Coding 很容易碰到一种情况：
你只是改：
A 页。
Agent 发现 A 页用了：
Shared Component。
于是它直接改：
Shared Component。
结果：
B。
C。
D。
三页一起变。
所以如果你知道：
这是正式网站，
就可以直接写：
如果修改 Shared Component 会影响其他页面，先停下来说明影响范围，不要直接修改。
这一句非常实用。
在 Slack Code 里，让团队先回一个「同意」
既然 Code Channel 本来就是多人协作，
不要急着让 Agent Build。
可以先贴：
现在。
要变成。
不能动。
然后让相关人确认：
产品：
需求正确。
设计：
视觉边界正确。
工程师：
技术限制正确。
确认完成，
再让 Agent 往下做。
真正节省的不是：
这 30 秒。
而是避免二十分钟后才有人说：
「等等，我不是这个意思。」
接下来再看 Slack Code 的 Plan
Slack Code 可以让 Agent 在专属 Code Channel 里呈现：
Planning Document。
Code Diff。
Live HTML Preview
等工作内容。
所以三格写完以后，
下一步才是：
看 Agent 的 Plan。
这时你只需要问：
它的计划有没有违反刚才三格？
看 Plan 时只检查三件事
第一：
它是不是在修：
真正的问题？
第二：
它做完是不是会得到：
你写的结果？
第三：
它有没有碰到：
你说不能动的范围？
如果第三个答案是：
有，
先不要 Build。
然后再看 Code Diff
Plan 是：
它说准备怎么改。
Code Diff 是：
它真的改了什么。
所以当 Diff 出来时，
还是用同一张三格卡检查。
不用突然换一套标准。
例如：
明明「不能动」写了：
桌面版。
结果 Diff 里出现：
Desktop Layout CSS。
就值得问：
为什么？
这比只看：
AI 说「已完成」
可靠很多。
最后看 Preview
如果是网站或界面修改，
Preview 才是最接近：
用户真正看到的结果。
这时又回到：
第二格。
要变成怎样？
例如你写：
手机第一屏不卷动就看到 CTA。
那就真的切到：
手机尺寸。
确认：
看不看得到。
不要只看：
桌面 Preview 很漂亮，
就批准。
所以今天的方法其实一路都不用换
开始前：
现在／要变成／不能动。
看 Plan：
对照三格。
看 Diff：
对照三格。
看 Preview：
再对照三格。
最后才批准。
这样团队不用每到一个阶段，
重新发明一套判断标准。
这和 Replit Plan Mode 教学有什么不同？
8 月 20 日我们已经教过：
AI 改 App 前先看 Plan，不先动程序。
今天再写一次：
「先看 Plan」
就会变成重复内容。
所以今天往前推一层：
Plan 出来以前，你自己先定义什么叫做成功。
Plan Mode 解决的是：
AI 准备怎么做？
今天这三格解决的是：
人类到底要它做到什么程度？
两个是上下游关系。
也不要把「不能动」误会成系统锁定
这一点一定要分清楚。
你在 Prompt 写：
不要改 Database。
不代表系统真的把 Database：
锁起来。
它首先仍然是：
给 Agent 的工作指令。
如果某个 Agent 本身拥有更大的 Repository、部署或数据权限，
真正的技术安全还是需要：
权限。
Branch Policy。
Review。
测试。
Deployment Control。
所以三格方法的用途是：
让目标与边界更清楚。
不是取代：
工程权限治理。
可以直接拷贝这个模板
在开始修改以前，先用下面三个条件理解任务。
现在：
【目前可以观察到的问题】
要变成：
【完成后可以直接验证的结果】
不能动：
【不允许修改的页面、功能、数据、组件或流程】
先提出你的修改计划。
如果计划必须超出「不能动」的范围才能完成，先停下来说明原因。
不要自行扩大修改范围。
一个完整例子
假设网站会员登录页，
手机版 Logo 被切掉。
可以写：
现在：
在 390px 宽度下，登录页顶部 Logo 右侧被裁切。
要变成：
在 360px～430px 的手机宽度下，Logo 都完整显示，登录表单位置保持正常。
不能动：
不改 Logo 图档、不改登录 API、不改桌面版、不改会员验证流程。
先提出计划，不要直接部署。
这就比：
Logo 坏掉了，帮我修。
清楚很多。
如果你不懂程序也可以写
因为三格根本不要求：
会 Coding。
你只要知道：
现在看到什么？
希望最后变什么？
哪些东西不要跟着改？
这也是 Slack Code 很有意思的地方。
Slack 官方现在就是希望：
非技术成员也能进入 Code Channel，
查看 Agent 正在做什么、
看 Preview、
提出回馈，
再由相关人员一起 Sign Off。
今天的一分钟方法
下次用 Slack Code 叫 AI 改网站或 App，
不要第一句就写：
帮我改好。
先填：
现在
问题现在长什么样？
要变成
成功后可以看到什么？
不能动
哪些正常东西必须留下？
然后才让 Agent：
Plan。
Build。
Diff。
Preview。
Review。
今天真正要记住的一句话
AI Coding 最容易出错的地方，不一定是程序写错，而是它成功完成了一个大家从来没有真正说清楚的需求。
所以 Slack Code 开始以前，
先不要急着让 AI 写。
先让整个团队对：
现在是什么。
要变成什么。
什么不能变。
有同一个答案。
后面 AI 跑得愈快，
这三格反而愈重要。
今天，和 AI 一起进步一点。
每天学会一个 AI 技巧。
每天节省一点时间。
每天提升一点能力。
SasaDaily，陪你一起成长。
