加载失败
原讨论基于一篇分析文章与代码审查，作者检视了用 LLM 生成的 Rust 重写 SQLite（Frankensqlite）并发现：代码虽能通过测试但在实现细节上存在严重性能缺陷（例如每条语句 fsync、未识别主键）。评论从该案例延伸出几条主线：LLM 本质上是基于训练数据的 token 预测器，裸模型与带工具/执行能力的 agent 效果差别大；要把 LLM 用在生产必须把验收标准、测试与规划流程前置。讨论还涉及具体工具与模型（如 Claude/Claude Code、Codex、Opus）、训练与微调技术（如 RLHF）以及这场变革对工程师技能与开发流程的影响。
多位评论者用实际案例说明 LLM 生成的代码常能“看起来正确”并通过单元测试，但在性能或边界条件上严重失准。文章与评论里提到的例子（如对 SQLite 的 Rust 重写 Frankensqlite）显示代码能通过测试却在实现上每条语句都 fsync、未利用 is_ipk 判定主键，导致极差性能，体现模型更像概率预测器而非理解者。其他反馈还指出模型会反复引入训练数据里常见但不良的编码习惯（例如 Python 随意新增属性），以及在提示未明确隐藏需求时输出看似合理却不合适的实现。结论是：仅凭“看似合理”的输出无法保证正确性或性能，尤其当基准与运行时约束未被显式说明时。
多数评论指出，避免 LLM 产出错误或低效代码的关键是把工程实践前置：先写好设计文档、验收标准和测试套件，再让模型实现。实证做法包括采用 TDD（先写测试）、在 AGENTS.md/DESIGN.md 指明约束、用 planning mode 让模型先产出分解与验收清单，然后按步骤实现与验证。评论者报告若缺乏这些约束，审查与修补模型产出会耗费大量时间，因此自动化单元/集成/性能测试是必需环节。把 LLM 当作需要监督的“初稿/自动补全工具”而非最终交付者，是多数实践者的经验总结。
评论普遍区分裸 LLM 与具备工具、执行与记忆能力的 agent；后者能调用外部工具、运行代码并做闭环验证，因此更能发现并修复运行时与性能问题。像 Claude Code、Codex CLI 或自建 harness 的 coding agents 可以直接执行测试/基准并迭代，而纯文本 API 只是生成建议。许多回复强调系統 prompt、工具调用和会话管理会显著影响结果，实用技巧包括使用检入点/分支回滚、在 harness 中加入 invariant 检查，以及把 agent 视为带执行能力的编程协同体。结论是生产级编码更像是“LLM + 工具 + 执行环境”的组合，而非单纯的模型输出。
多数评论强调 LLM 本身是技能的放大器：会把有能力的人变得更快，而把缺乏架构与问题分解能力的人放大为产生低质量产出，呈现明显的双峰质量分布。资深工程师会在提示、规划、验收与工具链上投入前置工作（写规范、设 guardrails、管理 agent），从而获得高产能；而只给宽泛请求的用户通常得到“看似合理”的但不可用的代码。讨论还指出岗位会随之变化：未来更值钱的是架构、沟通、测试与评审能力，而非单纯敲代码的熟练度。多数人建议通过刻意练习 agentic 工程、阅读设计模式并大量复审 PR 来培养这种判断力。
多个评论描述 LLM 在编码时存在“越挖越多”的行为：当实现不佳时模型倾向于加入补丁、专用快速路径或新的抽象层，而不是删除冗余或死代码，导致代码膨胀与技术债务。这种行为一方面反映训练数据中删除/重构示例较少，另一方面与模型的‘生成更多 token’先验有关，结果是迁移/合并经常不彻底。对策建议包括训练专门的清理/删除模型、用仓库补丁做强化学习或在工作流中强制分支回退与重写策略。也有评论提到少数前沿模型或特定 harness 在识别冗余并删除上已有改进，但仍非普遍现象。
当 agent 间互调成为常态，评论建议 API 层应返回机器可验证的契约元数据（例如响应同时包含 JSON Schema、延迟、数据新鲜度等），让调用方能自动判定是否满足约定。多数人主张把业务验收写成可自动运行的 AI evals（自动化评测套件），把口头或模糊的需求形式化为可执行的测试与基准。另有观点认为在可验证领域（代码、数学）可以用合成数据与强化学习微调模型，以同时优化可行性与性能。总体建议是把测量、SLO 与验收标准嵌入开发与 API 层，像分布式系统中的 SLO/熔断机制一样降低盲目自动化的风险。
LLM: 大规模语言模型（Large Language Model）：基于概率预测下一个 token 的模型，用于生成文本与代码。它擅长基于训练数据的模式输出“看似合理”的实现，但并不保证理解运行时约束、性能或隐含需求。
agent / coding agent: agent（或 coding agent）：在 LLM 之上加入工具调用、执行环境、记忆與编排的系统。与裸模型不同，coding agent 可以实际运行代码、执行测试、访问文件/网络并迭代修复，从而实现闭环验证。
planning mode: planning mode（规划模式）：一种交互/工作流，让模型先产出设计文档、任务分解与验收标准，再按计划实现，有助于减少走偏与重复修补。
RLHF / RLVR: RLHF（Reinforcement Learning from Human Feedback）与类似的强化学习微调方法：使用人类反馈或验证信号对模型进行微调以调整输出倾向，可能屏蔽或放大训练数据中的某些模式。
AI evals: AI evals：自动化评测框架（如 ai-evals.io 的实践），用可重复的测试、用例与基准量化模型在特定任务上的正确性與性能，便于把业务验收标准形式化。
TDD: TDD（测试驱动开发，Test-Driven Development）：先写测试再实现功能的开发习惯，评论中被视为把 LLM 生成代码变得可验证与可交付的重要方法。