最近刷卡帕西的推，发现他说的LLM写代码会遇到问题，我自己也经常遇到： 他的原话：“模型们替你做出错误的假设，然后就跟着他们走，根本不经过核实。他们不管理自己的困惑，不寻求澄清，不提出矛盾，不提出权衡，应该反驳时也不反驳。” “他们真的喜欢把代码和API搞得太复杂，膨胀抽象，不清理死代码......在1000条线路上实施膨胀的建筑，而100条线就足够了。” “他们有时仍然会更改或删除一些他们不够理解的注释和代码，作为副作用，即使这些内容与任务本身有直接关系。 我自己会让LLM写进.md 的四条原则 1. 在编码前三思 别妄下定论。不要掩饰困惑。表面权衡。 大型语言模型通常默默选择一种解释并执行。这一原则强制要求显式推理： 明确陈述假设——如果不确定，请询问而非猜测呈现多种解读——当存在歧义时，不要默默选择必要时反驳——如果有更简单的方法，就直言不讳困惑时停止——指出不清楚的地方并寻求澄清 2. 简洁优先 只需最小限度的代码来解决问题。没有任何猜测性内容。 遏制过度工程的倾向： 除了被要求的内容之外，没有其他功能 一次性代码无抽象 没有“灵活性”或“可配置性”，只要是没被要求的对于不可能的情景，没有错误处理 如果200行可以变成50行，那就重写它 测试内容：高级工程师会说这太复杂了吗？如果是，那就简化。 3. 手术变更 只触碰你必须触碰的部分。只收拾你自己的烂摊子。 编辑现有代码时： 不要“改进”相邻的代码、注释或格式不要重构那些没坏掉的东西 即使你会用不同的方式，也要匹配现有的风格如果你发现了无关的死代码，要提及——不要删除当你的更改产生孤儿时： 移除那些是你自己更改导致没用到的导入/变量/函数除非被要求，否则不要删除已有的死代码测试内容：每一行更改都应直接追溯到用户的请求。 4. 目标驱动执行 定义成功标准。循环直到确认。 将关键任务转化为可验证的目标： 而不是...... 变身为...... “添加验证” 改为 写无效输入的测试，然后让它们通过” “修复漏洞”改为 “写一个复现它的测试，然后让它通过” “重构X” 改为 “确保考试前后通过” 对于多步骤任务，请提出简要计划： 1. [Step] → verify: [check] 2. [Step] → verify: [check] 3. [Step] → verify: [check] 强有力的成功标准让LLM能够独立循环。薄弱的标准（“让它奏效”）需要不断澄清