AI 工具已经这么多，为什么还要做自己的工作台？

读到这里，你可能已经有了另一个疑问。

“我用的 AI 工具已经能读资料、写内容，有些还能帮我操作。再花时间做一个自己的工作台，会不会只是把别人做好的东西重新做一遍？”

这个问题值得认真回答。毕竟，写代码需要时间，让工具一直能用也需要精力。对正在考虑学习方向的人来说，还要决定哪些晚上、哪些周末，值得放在这里。

如果只是为了把今天的周报写完，现成工具已经顺手，那就继续用。一个好用的工具，不会因为不是自己写的，就少解决一点问题。

而自建的理由，通常从两个地方出现：你确实有一件事情，现成工具接得还不够好；或者，你想亲手理解，一个带 AI 的产品怎样从想法变成可以使用的东西。这两个理由都成立，但它们期待的收获不一样。

有时，费劲的是围绕任务的那些小动作

接着上一份周报往下想。

第一次，你把工作记录交给 AI，得到草稿，改完就用。到了下一周，事情又从头开始：找笔记，挑出本周的任务，把团队固定的格式贴进去，再提醒它不要把讨论中的想法写成已完成。

其中某一步做起来并不难。让人疲惫的是，你已经解释过同一件事，下次还要再解释。

当然，现成工具可能就有保存要求、连接资料等功能。先去了解它们，往往比马上开发更省力。如果用好这些能力，麻烦就消失了，自建的必要性也会随之减少。

但也可能还有一个很具体的地方没有被接住。例如，你希望每条进展旁边都能看到对应记录；还没确定的事项，应该单独放在待确认区。你不想在正文里来回找，更不想每次靠自己记住哪些内容还没查实。

这时，自建的目标终于清楚了一点：让你按照熟悉的方式检查周报，在确认事实之后再处理表达。

它可以很小。不必超过通用产品的全部能力，只要这个改动对你正在做的事情有用。至于是否真的减少了麻烦，还要用几次再判断，不能靠“定制”两个字提前宣布成功。

工作台给一件事，留出了可以反复使用的位置

我们可以先把“工作台”这个词说得朴素一点：它是一个地方，让你准备材料、推进工作、查看过程，并处理最后的成果。

还是周报。开始时，你需要知道这次选中了哪一周的记录。处理中，你希望分清正在查询、查询失败与已经整理完成。草稿出来后，你需要检查来源，补充 AI 不知道的情况，再决定使用哪一版。

这些事情放在一起，才构成了你实际经历的工作。一个输入框能接住其中一部分，而一个适合这项任务的界面，可以把那些容易遗漏的环节摆到眼前。

比如，把未确认的进展单独列出来，你就不必在长回答里反复寻找问号；让每条结论旁边留有材料入口，核对时就少一次猜测。这里的价值来自人的动作变得顺手，不能只看多了几个按钮。

也因此，工作台不必把所有步骤都交给 Agent。一些要求可以固定下来，一些需要根据材料作出的选择再交给模型。Anthropic 在 《Building effective agents》 中建议从简单方案出发，只在结果确实需要时增加复杂度。这个原则也适合这里：先接住反复发生的需要，再考虑更多能力。

这样的项目，对前端开发者有一个容易产生兴趣的地方。你熟悉的页面、输入、等待和反馈，又有了具体对象。以前也许是在帮用户完成一次提交，现在则要让用户看懂一个会继续执行任务的系统，知道自己什么时候应该参与。

为了学习，自建还有另一种收获

不过，即使暂时没有非定制不可的需求，亲手做一遍也可能值得。

只使用现成工具时，我们通常关注“这次好不好用”。一旦开始开发，问题会变得不同：它为什么知道该读哪份资料？没有读到时怎么告诉用户？用户修改过的事实，下一次还会不会被忽略？

这些问题不是多读几个名词就能消失的。你需要作出一个选择，做出来，看结果，再决定要不要改。

假设你最初让 AI 自动把所有任务都写进周报。试用后发现，有些任务只是你帮同事临时看了一眼，放进去反而让成果显得含糊。于是，你增加了一个选择材料的步骤，让人先决定本周真正需要报告的工作。

页面可能只多了一个很普通的选择动作，但你已经理解了一件重要的事：输入更多，并不自动等于更懂用户。哪些材料适合这次任务，本身就需要判断。

再假设你把所有异常都显示为“生成失败”。真正使用时才发现，找不到资料、模型暂时不可用和用户主动停止，接下来该做的事情完全不同。你开始把这些情况区分开，让人知道怎样继续。

通过这样的尝试，你能看到自己的决定怎样影响结果，而后来的修改，又怎样影响一个人能否把事情做完。每一次这样的往返，都比单纯记住“Agent 可以调用工具”具体得多。

如果学习是主要目标，就不必先证明自己做的工具比成熟产品更强。可以先问：这次实践，有没有让我理解一个原来只能靠猜的问题？理解之后，我能不能亲手改动它？

“自己的”，也意味着有人需要照顾它

说到这里，也该把成本放到眼前。

工具第一次跑起来之后，事情还没结束。资料的格式可能变化，外部服务可能暂时不可用，自己以为清楚的按钮，换个人用就可能产生误解。这些问题不会因为功能少，就完全不出现。

假如只是你自己练习，可以把范围限制得很小。准备给同事使用时，就需要更认真地考虑，谁有权访问哪些材料，失败之后怎样恢复，出问题时由谁处理。愿意承担的责任不同，适合做出的东西也不同。

“自己的工作台”同样不能自动等同于“数据只留在本地”。如果请求交给外部模型处理，相关内容仍可能发送给相应服务。能否本地处理、怎样保存资料、外部服务有哪些规则，都取决于具体设计。

费用也一样。模型调用、服务运行和维护时间，都需要计算。自建给了你调整的空间，不等于每一种用法都会更便宜。

所以，我更愿意把这里的“自己的”理解为：你逐渐知道它为什么这样工作，哪里可以修改，以及修改以后由谁负责。 这份理解，比单纯拥有一个域名或一份代码更接近学习的目的。

先找到一件值得亲手理解的事

回到开头的问题：现成 AI 工具已经很多，为什么还要做自己的工作台？

为了使用，先看现成工具能否接住你的需要；为了定制，先找一个反复出现、说得清楚的不便；为了学习，则给自己一次把想法做出来、再根据真实结果修改的机会。

你可以从周报开始，也可以选自己更熟悉的事情。先观察一次完整的工作：哪里总要重复准备，哪里最需要确认，结果出来以后还要做什么。把其中一个问题写清楚，比先收集几十个功能更容易找到起点。

随着 AI 工具不断变化，有些曾经需要自建的功能，可能很快就能直接使用。这并不妨碍我们继续学习，只是提醒我们，投入的理由要想明白。今天为理解而做的练习，与准备长期维护的产品，可以有不同的完成标准。

我期待这个专栏带来的，也是这样的过程：你开始能把“我希望它更好用”说成一个具体的问题，能试着做出改变，也能看见改变是否有效。新的工具再出现时，你便多了一份判断和尝试的依据。

不过，花时间做一个项目，最后总该留下点能拿出来的东西。下一篇，我们就具体聊聊：做完一个 Agent 项目，你应该拿得出什么？