假设你替一间小型工作室做预约服务。你向 AI 描述需要的功能：选择时段、填写数据、寄出通知，再提供一个让店主查看行程的后台。当这些要求能够逐步变成可操作的画面，原本看似遥远的产品，开始有了轮廓。
但店主看完之后，可能只问一句：「客人临时改时间，我还需要在三个地方各改一次吗？」
这个问题让产品回到现场。画面已经能动，工作却可能没有变轻松。以下的工作室是用来推演的假设情境；我想藉它讨论，当 AI 让部分实现变容易，产品应该如何重新说明自己存在的理由。
代码退到幕后，谁的注意力改变了？
对大多数用户来说，代码一直在幕后。他们原本就在意能否完成预约、找到信息、把事情办妥。这些需求早于生成式 AI，也不会因为工具更新就自动改变。
新的变化发生在创作者这一侧。对部分任务而言，过去必须逐段翻译成程序的要求，现在可以先用自然语言描述，再透过执行结果、画面与回馈逐步修正。注意力因此有机会从每一步怎么写，移向要做什么、结果是否符合期待，以及哪里仍需介入。
我用「AI 遮住代码」形容这个转移。被遮住的是部分实现过程，底下的数据结构、执行条件与错误依然存在。当结果偏离预期，创作者仍需要判断问题出在哪一层，也需要有能力打开那层抽象。
这种转移有一个容易忽略的前提：你得知道怎样才算完成。描述「做一套预约系统」很容易；说清楚两人同时抢最后一个时段时该发生什么，才开始碰到产品的边界。需求中的空白，终究会由某个人或某段系统行为补上。
实现加速也让这些空白更快变成具体行为。画面越完整，团队越容易把默认选择当成已经讨论过的决策。因此，看见可用的成果时，仍值得回头问：哪些规则来自真实需求，哪些只是生成过程替我们做了决定？
做得出来之后，差异从哪里来？
如果一类功能更容易被做出来，拥有这项功能所能形成的差异，就值得重新检查。预约表单、通知范本与管理列表都很有用，但当相近的组合更容易出现，用户就有更多理由比较：哪一套符合自己的流程？搬过去要花多少力气？出问题时找得到人吗？
我的判断是，AI 会让某些靠实现门槛维持的差异承受更大压力。这个判断有范围：容易描述、容易验证、已有成熟模式的功能，与需要特殊演算法或深厚领域知识的系统，面对的条件并不相同。
产品的价值本来就应该从用户出发。改变的是投入资源的理由。当多做一个功能所需的成本下降，团队更容易沿著「还能加什么」一路扩张；可是用户理解功能、设定规则、迁移数据的成本，未必跟著下降。对店主而言，多一个选项也可能多一个必须做的决定。
因此，实现能力增加之后，取舍会变得更具体。你愿不愿意只服务某一种工作室？愿不愿意为了清楚的流程，放弃少数看似通用的功能？越容易制作，越需要确认每个新增项目究竟替谁减少了什么负担。
METR 在 2026 年的技术工作者调查中，刻意区分做事的速度与产出带来的价值，也提醒读者：自我报告的提升不等于客观验证过的成效。这份调查没有回答哪种产品会成功，但它提出的测量区分很有用。更快完成一个没人需要的后台，仍可能只是更快消耗了注意力。
这也影响值得累积的资产。对工作室的理解，可以逐步变成合理的默认、恰当的例外处理与容易采用的流程。竞争者即使复制了画面，也未必知道每个选择背后的原因。这种理解需要持续与现场核对；一旦只剩下团队内部的想像，它同样可能成为包袱。
从预约功能，走到预约成立
回到那间工作室。假设它只有一位主理人，白天接待客人，晚上回复讯息。客人的需求散落在通讯软件、日历与纸本纪录里。主理人想减少来回确认，也希望保留处理熟客与特殊需求的弹性。
一个可以送出表单的页面，解决了数据收集。但要让预约成立，还有许多判断：服务前后是否需要准备时间？客人选到的时段是否仍然可用？改期后，旧时段何时释出？通知没有送达时，谁会知道这件事尚未完成？
这些细节会改变产品如何运作。假如日历同步有延迟，系统就不应只凭一份过期数据宣布预约成功。假如主理人必须先确认特殊需求，界面就需要清楚区分「已收到申请」与「已确认预约」。两句文案之间，隔著用户接下来要不要出门的决定。
定位开始变得清楚，是因为我们知道要改善哪一段工作。功能仍然重要，只是需要和承诺、证据接在一起。
| 功能 | 对用户的承诺 | 可以怎么验证 |
|---|---|---|
| 时段选择 | 客人选到确实可以提供服务的时间 | 检查冲突与重复预约，追踪需要人工修正的比例 |
| 改期处理 | 调整一次就能让相关纪录一致 | 观察一次改期需要多少操作与来回讯息 |
| 通知与提醒 | 双方知道目前状态与下一步 | 检查送达情况、状态误解与人工补通知次数 |
表格里没有默认漂亮的成果数字。真正导入时，应先观察原本的流程，再看使用后的差异，并把设定、核对与补救的时间一起算进去。若少回了几则讯息，却增加每天检查 AI 是否做错的负担，省下的时间可能又以另一种形式回来。
承诺也要落在产品能影响的范围内。提醒可以帮助客人记住时间，却无法保证每个人都准时出现。比较负责任的做法，是把可观察的状态呈现清楚，让店主及早知道哪些预约仍待确认，并保留联络与调整的空间。把成效说得精确，会直接影响用户建立什么期待。
理解现场也会影响竞争对象。这套服务可能是在和店主已经熟悉的通讯软件加纸本日历竞争。新的系统必须好到值得换掉既有习惯。功能相同与否，只是比较中的一部分。
接受委派之后，界面要让人看见什么？
当店主可以直接说「把周五下午的预约移到下周」，产品就开始承接委派。这句话省略了许多操作，也省略了许多条件：是全部移动吗？客人同意了吗？下一周有没有足够时段？
好的互动需要把这些条件带回可判断的画面。系统可以先列出受影响的预约、提供可行时段，让店主检查后再通知客人。对暂时无法安排的项目，保留明确状态与接手入口。用户能知道进行到哪里，才有条件放心把工作交出去。
这也说明了聊天框的限度。自然语言适合表达意图与补充情境；一周的空档放在日历上，通常更容易比较。多笔改期的前后差异放在表格里，也更方便检查。界面可以依任务切换表达方式，让描述、比较与确认各自有合适的地方。
系统用来判断的依据也应该能被检查。例如「下午有空」究竟来自最新行程，还是店主上周说过的一句话？产品不必展示全部推理过程，但需要在影响安排的地方，提供可核对的数据与限制。用户才知道要修正哪个条件，让后续处理回到正轨。
控制感还包括改变心意的能力。通知尚未寄出时能否取消？寄出后能否补发更正？自动处理的范围是否清楚？这些问题应该在设计流程时就被回答，因为它们决定用户愿意委派到什么程度。
如果每一步都要用户重新核对，委派的价值会被吃掉；如果每一步都默默完成，用户又可能失去必要的判断机会。产品需要找出真正值得停下来的节点，并让其余步骤的状态保持可见。这是一项与情境有关的设计工作，很难用「自动化越多越好」取代。
看不见的工程，仍然决定体验
简洁的界面会把更多责任留给底下的系统。两个人同时预约，数据必须保持一致；通知重试，不能让客人收到互相矛盾的讯息；系统中断后，接手的人需要知道哪些动作已经完成。
这些工作可能不容易在展示影片里被看见，却会在日常使用中反复决定信任。尤其当产品替用户执行动作，错误会离开屏幕，影响别人的安排。工程品质于是直接成为产品承诺的一部分。
Anthropic 在 2026 年介绍 Managed Agents 的工程文章中，描述了将持久事件纪录与执行环境分离的设计，使执行组件失败后仍能恢复工作。这个案例提供了一个具体提醒：让使用界面更简单，背后仍需要安排状态保存与故障恢复。它并不表示每个预约服务都需要同样的架构。
工程也仍可能是产品最重要的差异。极低延迟、特殊数据处理、离线能力或难以复制的整合，都可能直接决定某个需求能否被满足。认为所有代码都会变成廉价零件，会错过这些具体限制。
我更在意的是，团队能否说清楚每一项技术投入如何改善结果。对这间工作室，可靠地防止重复预约，可能比多一种生成讯息的语气更值得先做。选择用固定规则处理已知流程，也可能比让模型每次重新判断更合适。知道何处需要 AI，何处需要确定性，本身就是产品能力。
重新写下产品的承诺
如果要替这个假设中的产品写一句介绍，「具备 AI 排程、自动通知与智慧管理的预约平台」能交代功能，却仍让店主自己猜它和现况有什么关系。
我会试著写得更具体：「协助独立工作室集中处理预约与改期，减少反复确认，让主理人在需要判断的地方接手。」这句话不是已被证明的成果，而是一个需要透过设计与使用验证的承诺。它选择了服务对象，也让团队知道哪些事情应该优先。
范围缩小也让第一步容易验证。可以先把单人工作室的一次改期做完整，确认旧时段释出、纪录更新与通知都能衔接，再考虑多人排班。这样的顺序让团队有机会从真实使用中学习，避免拿功能数量替代对问题的理解。
接下来有四个问题必须回答：我们服务的是谁，他原本怎么完成工作？我们希望改善哪个可观察的结果？要用什么证据判断改善真的发生？当系统做不到时，谁接手、怎么补救？
这四个问题可以用来检查每一次新增功能。如果一项功能只让产品看起来更聪明，却无法连回任何一个答案，就值得延后。省下的实现时间，可以拿去观察真实流程、简化设定，或把失败时的体验做完整。
对设计师与开发者而言，这也让工作之间的连结更紧密。问题定义需要理解技术边界，技术选择需要知道用户在意的结果；设计则要让这些选择成为人能理解、操作与信任的流程。谁负责把这条线接起来，谁就有机会创造难以用功能清单衡量的价值。
当 AI 让部分实现变容易，我希望得到的是更大的余裕：更早验证一个值得做的问题，更有耐心处理那些不容易展示、却每天都会发生的例外。
代码可以退到幕后。当那位店主再次遇到临时改期，知道只要处理一次，而且能看见事情确实完成，产品才有了被继续选择的理由。