如何让 coding agent 更大胆 更有点子

关键不是对它说“大胆一点”，而是：允许它挑战方案、给它探索空间，同时把不能碰的边界说清楚。 比如你让它“优化这个聊天页面”，它很容易只调间距、颜色。可以改成这样： 先别写代码。目标是让用户更容易发现未读消息，不限于修改现有布局。 先给出三个有明显区别的方案：最小改动、结构重设计、一个你认为值得尝试的非传统方案。 每个方案说明解决什么问题、牺牲什么、怎么验证。不要拿三个配色版本冒充三个方案。 你可以质疑我提出的实现方式，但不能擅自改变产品目标。 选出你最推荐的方案，解释理由。 想让它执行也更主动，再补一段： 选定方向后，你可以自主查代码、修改相关实现、补测试，不必每一步都问我。 可逆、局部的实现决策自行处理，并在最终汇报中说明。 新增生产依赖、修改公共接口、数据库迁移、删除数据、部署上线前必须确认。 遇到障碍时先尝试替代路径；确实需要我决策时，带着选项和推荐方案来问，不要只汇报“做不了”。 这里其实是两个不同问题。 “有点子”需要先发散再收敛。不要让它看到需求就立刻开写；先让它研究现有实现、找不同解法、比较取舍。也可以要求它：“如果不沿用当前架构，你会怎么解决？再判断其中哪些值得带回现有项目。”这比单纯要求“创新”更具体。 “更大胆”需要明确授权。告诉它哪些事情可以自己决定、哪些必须问你。只说“谨慎修改、最小改动、不要影响现有逻辑”，同时又希望它主动重构，要求本身就在打架。 还要给它判断好坏的依据。比如“减少用户完成任务的步骤，同时保留键盘操作能力”，比“做得惊艳一点”更容易产生有价值的设计。允许它提出超出当前范围的建议，但不要让它直接夹带进实现。 我会把最核心的一句写进 Agent 指令： 对方案有主见，对执行有边界，对结果有证据。不要默认我的实现建议就是最佳答案；发现更好的路径时，具体说明收益和代价。能在授权范围内自行推进的事直接做，但不要把猜测当事实、把未测试当完成。 大胆不等于关掉权限确认，也不等于多改代码。真正想要的是：它敢提出不同解法，而且能把其中一个验证出来。