“不要替模型做它自己能做的事”
很多 AI 应用的问题，不是模型能力不够，而是产品替模型做了太多事。
开发者为了提高眼前的成功率，搭建 AST 解析、语义索引、差异应用器、固定工作流和复杂提示词。这些脚手架在当下可能有效，却也把模型限制在预先设计好的格子里。
模型只能填空，不能自己寻找路径。产品因此获得了短期的确定性，却失去了随模型成长的可能性。
不只看成功率，还要看能力的斜率
文中转述了 Claude Code 创造者鲍里斯·切尔尼的一个关键判断：与其为模型建立复杂的代码处理系统，不如给它终端、bash 和读写文件、搜索代码的能力，让它像一个刚加入团队的工程师那样工作。
这种方式在最初未必表现最好。真正重要的不是某一版模型的成功率，而是这条路线的斜率。
模型每隔几个月都会增强。产品没有写死的部分，可以直接得到模型进步带来的收益；产品预先固化的抽象，却不会自动消失，反而可能挡住新能力，还要继续维护。
所以，复杂脚手架未必是资产。凡是建立在“模型以后也做不到”这一假设上的设计，都可能成为技术负债。
简单是为了让能力长出来
这里的简单，不是追求形式上的优雅，也不是拒绝必要的工程约束，而是尽量不给模型预设能力上限。
Claude Code 后来被用于数据分析、Kubernetes 管理和周报写作，并不是因为产品事先设计了这些功能，而是因为它提供了一个足够通用的入口。
如果一开始把它定义成代码编辑器插件，产品边界也就随之被固定。用户只能使用设计者已经想到的功能，很难探索设计者没有想到的用途。
这也是通用工具和功能型应用之间的重要区别：前者提供能力，后者规定路径。
每个按钮都在裁剪可能性
终端看起来复古，却拥有很强的表达力。它不替用户预设任务类型，也不轻易限制工具之间的组合方式。
图形界面的按钮更容易使用，但每增加一个按钮，也意味着产品替用户和模型做了一次选择。按钮本身没有问题，问题在于这种裁剪是否必要。
用户体验仍然应当简单，但简单不等于把底层能力切碎。更合理的方向，是让系统吸收操作复杂度，同时保留模型解决问题的空间。
先判断这件事会不会很快被模型接管
我认为，写下每一行胶水代码、每一个条件分支和每一段固定提示词之前，都应该先问一个问题：这是模型长期无法完成的事，还是它很快就能自己完成的事？
如果属于前者，就应由产品提供可靠的机制；如果属于后者，过早固化往往得不偿失。
模型时代的产品，不应只是把模型嵌进旧软件，而要尽可能接近模型本身的形态：提供通用工具、足够权限和清晰反馈，把路径选择留给模型。
产品真正需要设计的，不是模型每一步应该怎么走，而是它可以在什么边界内自由行动。