AI 最容易让人高估的，不是生成能力，而是它仿佛也能接手判断、取舍和责任。越接近这些边界，我越不会把最后决定外包出去。
我并不抗拒把大量执行动作交给 AI
我现在已经很习惯让 AI 参与很多工作：整理材料、压缩上下文、补回归测试思路、先给出一版结构、把零散记录改写成更能阅读的段落，甚至在代码层直接参与排查、修改和验证。对独立开发者来说，这种提速非常真实，因为它减少的不是抽象上的劳动，而是很多原本必须自己重复完成的机械动作。
但有些能力一旦交出去，产品主线就会开始偏。危险不在 AI 明显做不到，而在它看起来能做，让你在关键位置也省掉判断。
第一类：最后的判断，不能外包
AI 很擅长给出多个版本，也很擅长把每个版本都说得像有道理。它可以帮你列选项、补背景、整理论据，甚至把问题讲得比你自己更完整。但做产品最关键的时刻，往往不是看见了多少可能性，而是砍掉大多数可能性，决定现在到底要相信哪一条路。
比如首页该不该继续只是文章流，about 页到底应该讲什么，某个产品入口现在该不该留下，Cloudflare 构建阻塞修完之前能不能算“可发布”，这些都不是语言组织问题，而是方向判断问题。AI 可以帮我把材料铺开，却不能替我承担“现在就按这个方向走”的责任。因为最后承担结果的人是我，不是模型。
第二类：取舍，不能外包
为什么 AI 容易把取舍讲成“都可以保留”
判断决定方向，取舍决定代价。它要求你承认资源有限、时间有限， 也要求你承认一个人不可能同时把所有事都做到最好。
AI 常把事情讲全，于是每条路都值得保留、每个模块都能再补一点。真实工作里，最重要的往往是删掉。
删掉一个现在不该展开的入口，删掉一个会把系统拖进额外维护成本的流程，删掉一个虽然看起来完整、其实和主线关系不大的功能，这些动作都带着明显的痛感。
这些删除会改变未来几周甚至几个月的工作形状。长期把这种取舍交给 AI，很容易得到一个解释充分、结构完整、边界却越来越厚的系统。
我自己就差点犯过一次：当时 AI 建议把 OnlyBegin 的一篇稿子、MakePlans 的一段说明和一个还没复核完的 QA 结论合并成同一版文案，看起来很顺，但我最后停了下来，把它拆回去，只保留已经完成复核的那一条。
第三类：责任，不能外包
责任不是一句价值观口号，而是一个非常具体的问题：如果这个版本发出去出问题，应该先回头查哪一步？
如果一篇文章越来越不像真实工作现场，是谁放任它滑过去的？如果一个功能入口还没准备好却被提前暴露，是谁做了这个决定？这些问题最后都不会落到 AI 身上，只会落回我自己。
独立开发最大的优势之一，是判断链路短；最大的压力之一，也是没有人能替你兜底。
AI 可以帮我减少很多重复劳动，但它不能替我对一条路由负责，不能替我对一次发布判断负责，也不能替我对一篇文章的立场负责。只要我把这个边界忘了，AI 就会慢慢从协作者变成“我为什么这次先不想清楚也没关系”的借口。
我印象很深的一次，是差点把一个还没确认完的 OnlyBegin 公开稿直接发出去，因为 AI 已经把措辞润得很顺了；但我回头检查时才发现，里面还把一个只在草案里的 MakePlans 决定写成了既成事实。那次如果我没亲自停一下，责任就会先从我手里滑走。
这三类能力越到后面越重要
执行层越容易被提速，判断、取舍和责任越重要。对独立开发者而言，产品、工程和表达能保持同一条主线，不是因为工具统一，而是最后做决定的人没换。
所以我把 AI 放在更明确的位置：它帮我更快抵达判断、减轻机械劳动、整理真实工作，但不替我拥有判断或承担后果。
所以我现在更愿意把 AI 当成放大器，而不是代笔人或代理人
我愿意把越来越多的“做”交给 AI，却不把“为什么这样做”“为什么不做别的”“出了问题谁负责”交给它。后者一旦外包，主线就会越来越不像自己。
把边界写回实际工作
这篇不能只停在“判断不能外包”的价值观上。对 OnlyBegin 来说，不能外包的是哪些文章该公开、哪些未来草稿必须继续 QA、哪些 source-synthesis 需要复核、哪些 AdSense 风险不能为了数量而放过。
比如我会亲自决定：一篇稿子如果还没过两轮人工复核，就不能进公开流；MakePlans 的改动说明如果还没和真实发布状态对齐，就先放进内部记录，不直接写进首页文案。这些都是执行之外的责任。