让 ai 写测试总是会出现这些问题： 1、错误的断言数据，比如会猜测某个字段的实际情况去错误断言，基于这个错误断言写出来的逻辑也会错误，从而出现：测试 ok，正式运行寄了 2、懒惰不堪，测试用例懒得写，覆盖不完整，想的不够边界 3、瞎几把测试无用的逻辑或断言，浪费 Token 写出一些没必要的测试，如测试常量返回（我都写常量了你测个 damn，改个常量值测试也得崩），也就是不去测真正的业务逻辑 4、部分情况会出现在测试中复写业务逻辑，而不是进行导入使用（天啊，到时候业务改一下，测试一直不过，留个坑在那） 基于以上发现，我让 ai 给的提示词规则为： # AI 测试编写约束规则 ## 1. 断言数据准则 - **禁止猜测数据**：不确定的字段值必须先读取代码确认，或明确标注 - **使用真实数据源**：优先从代码中提取常量、类型定义、实际返回值 - **验证而非假设**：对不确定的业务逻辑，先问用户确认预期行为 ## 2. 覆盖率要求 必须覆盖： - **边界条件**：空值、null、undefined、空数组/对象、极值 - **错误路径**：异常抛出、错误返回、失败分支 - **核心业务分支**：if/else、switch 的主要路径 禁止遗漏： - 必须至少包含 1 个成功用例 + 1 个失败/边界用例 - 对于有明显分支的函数（如有 3+ 个 if），需覆盖每个分支 ## 3. 避免无效测试 **不要测试的内容**： - 常量的值（`const MAX = 100` 不需要测 `expect(MAX).toBe(100)`） - 第三方库的行为（除非是 mock 验证） - 纯类型定义（TypeScript 类型检查已覆盖） - getter/setter 无逻辑的直接赋值取值 **应该测试的内容**： - 包含计算、转换、判断的业务逻辑 - 数据处理流程（输入 → 处理 → 输出） - 副作用：API 调用、数据库操作、状态变更（通过 mock 验证） ## 4. 复用业务代码 - **绝对禁止**：在测试中重写业务逻辑实现 - **必须导入**：直接 import 被测函数、工具函数、常量 不知道各位有没有更好的 rule 和相关处理方案呢 1 个帖子 - 1 位参与者 阅读完整话题
最近看了一圈 OpenAI Codex、Claude Code、Gemini、DeepSeek、Qwen 这些东西，感觉 AI 编程工具的竞争方向已经明显变了。 以前大家主要在比： 哪个模型回答更准； 哪个模型写代码更快； 哪个模型上下文更长； 哪个模型 benchmark 分数更高。 但现在我感觉真正的重点开始变成另一个问题： 谁能把一个真实开发任务，从理解需求、读项目、改代码、跑测试、修 bug、解释改动，尽可能完整地跑完。 也就是说，AI 编程正在从“代码补全 / 聊天问答”，变成“Agent Runtime”。 我这里说的 Agent Runtime，不只是模型本身，而是这一整套东西： 模型能力； 工具调用； 终端权限； 文件系统读写； 测试执行； 长期任务规划； 子任务拆分； 上下文管理； 权限控制； 失败回滚； 成本控制； 最终验收。 这几个东西加起来，才决定一个 AI 编程工具到底能不能在真实项目里干活。 比如 Codex 的 Goal mode，本质上已经不是简单让模型“帮我写一段代码”，而是让它围绕一个目标持续推进。你给它的不是一句 prompt，而是一个可以验收的任务目标。 Claude Code 这边也越来越像一个工程协作者，不只是回答问题，而是会规划、会拆任务、会调用工具、会根据项目上下文不断调整。尤其现在很多工具开始强调 subagents、skills、workflows，方向已经很明显了。 Google 那边的 Gemini CLI、Antigravity、Managed Agents，还有 WebMCP 这些东西，本质也在往同一个方向走：让模型不只是“生成文本”，而是能直接使用环境里的工具，操作真实任务。 所以我现在越来越觉得，2026 年 AI 编程工具的核心竞争点可能不是“单模型智商”，而是下面几个能力： 第一，能不能稳定理解一个真实项目，而不是只会看单文件。 很多模型单独写一个函数都很强，但一进真实 repo 就开始迷路。真实项目里有历史包袱、有测试、有构建脚本、有隐藏依赖、有约定俗成的代码风格。模型如果不能理解项目结构，只靠局部上下文，很容易改 A 坏 B。 第二，能不能自己验证结果。 我现在对“只写代码不跑测试”的 AI 输出越来越不信任。真正有用的 Agent 应该至少能做到：改完代码后主动跑测试、看报错、修复、再跑一遍。如果项目没有测试，也应该能说明它验证了什么、没验证什么，而不是一脸自信地说“已经完成”。 第三，能不能控制改动范围。 这点非常重要。很多 AI 工具最大的问题不是写不出来，而是太爱顺手重构。一个小 bug，它能改一堆无关文件，甚至把项目风格都改了。对真实开发来说，这种“过度发挥”很危险。 我觉得一个靠谱的 Agent，应该能严格遵守类似这样的约束： 只改必要文件； 不改 public API； 不改数据库 schema； 不引入新依赖； 不重构无关模块； 失败时先汇报，不要硬编。 第四，能不能承认不确定。 我现在反而更喜欢那种会说“这里我不确定，需要你确认”的模型。最怕的是它明明没看懂，还装得很确定。AI 编程里，一个会阻止你犯蠢的模型，可能比一个特别会顺着你写代码的模型更有价值。 第五，能不能把成本控制住。 长任务 Agent 最大的问题是 token 和调用次数。你让它跑一个复杂任务，它可能读一堆文件、改一堆代码、跑很多轮测试，最后账单也很感人。所以未来 AI 编程工具不只是比效果，还要比单位成本下的有效产出。 这也是为什么我觉得 DeepSeek、Qwen 这些模型在国内开发者这里会很有讨论价值。只要能力接近，成本和可控性就会成为非常关键的因素。 我现在比较想测一个东西： 同一个真实 repo，同一个 bugfix 任务，分别交给 Codex、Claude Code、Gemini CLI、DeepSeek V4、Qwen3.7Max 看看结果。 不看宣传，也不只看 benchmark，就看几个实际指标： 是否能定位到正确文件； 是否能最小化改动； 是否能跑通测试； 是否会乱改无关代码； 是否会主动解释风险； 失败后能不能自我修正； 总共花了多少 token / 多少钱； 最终 PR 是否像人类工程师写的。 我感觉这类测试比单纯问“哪个模型最强”更有意义。因为真实开发里，模型强不强不是只看它会不会回答，而是看它能不能稳定交付。 我的一个判断是： 以后 AI 编程工具可能会分成两类。 一类是“聊天型模型”，适合问问题、解释代码、写小片段。 另一类是“工程型 Agent”，适合接真实任务、改项目、跑测试、生成 PR。 前者拼的是模型回答质量，后者拼的是整个执行系统。 而真正能改变开发流程的，应该是后者。 所以问题来了： 各位现在真实项目里更信哪个？ Codex？ Claude Code？ Gemini CLI / Antigravity？ DeepSeek？ Qwen？ 还是自己搭 MCP / CLI / 工作流？ 有没有佬已经在生产项目里把 AI Agent 当半个开发用了？实际体验是提高效率，还是制造更多 review 压力？ 9 个帖子 - 9 位参与者 阅读完整话题
不知道为什么，gemini 3.5感觉比以前更会胡扯了？我宁愿它坚持己见或者真的发现自己错了而立刻纠正，而不是我每次提出一个和它有些相悖的观点它就左右摇摆，来回吹嘘，这是科研哎，你让我到时候和审稿人也玩这套么？ （以下来自于同一个对话它的依次回复） 1 个帖子 - 1 位参与者 阅读完整话题
经过一上午的codex实测，发现GPT 5.5不仅能力不错，最重要的是 比5.4还更会说人话，自然语言表达更加清楚 王朝了 1 个帖子 - 1 位参与者 阅读完整话题
凌晨以来一直霸榜日榜榜一，刚截图的时候被反超了 网站是别的佬友做的，不得不说，好玩： 比比谁更会烧 Token！TokenArena：一个完全开源的 token 统计看板/竞技场（交互/UI 超精美） 开发调优 本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的帖子已经打上 开源推广 标签： 是 我的开源项目完整开源，无未开源部分： 是 我的开源项目已链接认可 LINUX DO 社区： 是 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出 最近公众号… OpenCode+自带M2.5刷token就是快（ 1 个帖子 - 1 位参与者 阅读完整话题