AI 写代码越来越强，但它不知道我们上周修了什么 bug，把 Bug 重新引入生产环境了

[huoru]

三个月前，我们花了两周时间修了一个 bug 。

用户账单偶尔会出现 ¥0.01 的误差。复现不稳定，线上偶发，客服一直在手动补差价。翻遍了日志，最后定位到一个经典问题：浮点数精度。

0.1 + 0.2 在 IEEE 754 里不等于 0.3，这个大家都听说过，但真的踩到还是很痛。

修复方案是把所有金额改成以「分」为单位存整数，展示时再除以 100 。改动不复杂，但涉及的地方很多，改完之后代码里到处是 amount * 100、Math.round()、/ 100，看起来有点丑，但能用，bug 消失了。

然后上个月，我让 Agent 帮我重构结算模块，优化一下代码结构。

它看到那堆乘除，觉得多此一举，顺手给「简化」了，改回了直接用浮点数。逻辑更清晰，代码更短，单元测试全过。

那个 ¥0.01 的 bug 悄悄回来了。

---

这件事让我开始认真想一个问题：

我们有代码审查，但我们需要「意图审查」。

这不是 AI 写了烂代码

大家讨论 AI 写代码，通常聚焦在输出质量上：架构合不合理、有没有 bug 、测试过了没有。

但我说的这个问题不一样。

Agent 那次重构质量是好的。逻辑清晰，可读性提升了，测试也没挂。它只是不知道「那堆看起来多余的乘除，是两周 debug 换来的」。

从它的角度看，price * 100 然后 / 100 是纯粹的噪音——数学上等价，白白增加了阅读负担。优化掉，天经地义。

你想想一个工作了五六年的老工程师，碰到这段代码会怎么做？

大概率不会直接删。他会皱着眉头想：「这里为什么要转成整数？不可能是手滑写的，一定有原因。」然后去翻 commit ，或者去问写这段的人。

这叫对不熟悉代码的谦逊感——被坑多了，知道看起来多余的代码往往不是真的多余。

AI Agent 没有这个。它被训练成「顺着干」，而不是「先问为什么」。代码看起来可以简化？简化它。逻辑看起来绕弯子？拉直它。它只会优化表面，不会追问历史。

新项目里这没问题，在一个有历史的真实代码库里，这会出事。

现有的方案都差点意思

每次我说起这个问题，大家都会推荐一些工具。我挨个想过，说说为什么都不够用：

注释：「// 不要修改这里，浮点精度问题」写上去当然有用。但你得先意识到这里需要警告，才会去写。当时修 bug 的人在想的是「终于修完了」，不是「三个月后的 Agent 可能会把这个改回去」。漏写的注释保护不了任何人。

AGENTS.md / CLAUDE.md：同理，你想到的禁忌才能写进去。但大多数坑是事后才知道是坑的，你没法提前把所有决策都整理成文档。

ADR / RFC：门槛太高，大多数团队第一个季度之后就不维护了。就算维护着，也是给人看的文档，不是供 Agent 在改代码前按需查询的。

Wiki / Notion / Confluence：文档会和代码脱节。「金额统一用分存储」这件事，可能在某个内部文档里提了一句，但 Agent 不会在重构代码前主动去翻 Confluence ，就算翻了，也是一堆非结构化的文字，未必能命中。

PR 描述：当时修 bug 的 PR 描述里可能写了原因，但埋在 GitHub 历史里，没人去翻，Agent 更不会主动去看。

每一个工具都是对真实问题的局部回应，但没有一个能在 Agent 动手之前，把「这里曾经踩过什么坑、为什么要这么写」这件事，可靠地送到它面前。

我们缺的是「意图审查」

现有的代码审查，回答的是：「这个变更实现得好不好？」

看 diff ，查正确性、风格、测试覆盖率。这个流程很成熟，也很必要。

但代码审查解决不了另一个问题：「这个变更，在已有的历史背景下，方向对不对？」

这个问题需要审查者记住代码库的历史，记得这堆乘除是两周 debug 换来的，记得某个绕弯子的写法是填过坑之后留下的疤。大多数审查者没这个上下文，就算是原作者，三个月后也可能忘了当时为什么。

所以我觉得我们需要一层新的审查，叫意图审查，发生在代码被改之前，而不是之后。

它问的是：

• 这块代码有没有被踩过坑？当时怎么处理的？
• 看起来「多余」的写法，是不是刻意为之？
• 有没有哪些「优化」是被明确否定过的？
• 这里有哪些不能动的隐性约束？

对人类工程师来说，这些审查以非正式的方式发生：发条消息、瞄一眼 commit 历史、和写那段代码的人聊三十秒。

对 AI Agent 来说，这根本不会发生。没有「去问问当时踩过坑的人」的等价操作。Agent 读当前代码，看起来可以优化，就优化了，历史上踩过的坑对它来说是不可见的。

意图审查要怎么做

要真的能用起来，得满足三点：

第一，决策必须是结构化的。

「金额统一用分存储，避免浮点精度」这句话写在 Wiki 上供人阅读没问题。但 Agent 需要的是：决定了什么、为什么这么决定、涉及哪些文件、哪些操作是被明确禁止的。自由文本把这些结构藏起来了，Agent 每次都要重新解析一遍，还不一定能命中。

第二，决策必须住在代码旁边。

Wiki 会漂移，Notion 会被遗忘，Slack 消息串会被淹没。唯一能和代码永远保持连接的是 git 本身。决策活在 git 里，就能跟着代码一起被 clone 、被 fork 、被带到三个月后还没接手过这块的人面前。

第三，查询必须自动发生，在改代码之前。

如果需要提醒 Agent 「先查一下历史决策」，它就不会查。这个步骤必须内嵌在正常工作流里，就像它在重构前会先 grep 符号定义一样，查历史的摩擦要低于直接动手的摩擦。

我做了个工具

我最近在开发一个叫 Mainline 的东西，把团队决策以结构化记录的形式存进 git 本身，让 Agent 在改代码前可以查询。

每条「意图记录」长这样：

• 决定了什么、为什么这么决定
• 考虑过哪些备选方案，为什么没选
• 识别出了哪些风险
• 涉及哪些文件，哪些操作是被明确禁止的

如果当时修浮点 bug 的时候封存了一条意图记录，三个月后 Agent 重构结算模块，运行 mainline context billing，就会看到：「金额统一用分存储，直接用浮点运算会导致 ¥0.01 偶发误差，已确认线上踩坑，禁止还原。」

那次「简化」大概率就不会发生了。

用了一个月，有几点出乎我意料：

摩擦不在我以为的地方。 我以为工程师会抗拒写这些记录，结果没有——因为 Agent 负责起草，工程师只是过目和调整。真正的摩擦在于：什么时候该封存一条记录？封太频繁是噪音，封太少会漏掉重要的坑。

收益来得比预期晚。 第一周感觉纯粹是额外负担。第三周开始出现「这段为什么要这么写？」的时刻，答案就在日志里。第六周，Agent 开始不用提示就把历史决策当作上下文来用。

两个人协作比一个人用难得多。 一个人用的时候，意图记录是写给自己的备忘。两个工程师同时工作时，它变成了一个协调协议——你得知道对方封存了什么，你们的方向有没有冲突。

工具是开源的（ Apache 2.0 ），目前小范围私测，地址在 mainline.sh 。

https://github.com/mainline-org/mainline

说回这件事本身

AI Agent 现在在很多团队里写相当比例的新代码。代码审查的负担没有降低，反而在升高——因为审查 AI 写的代码认知成本更高，你没办法像问同事一样问它「你为什么这么改」。

现在的情况是，每次代码审查都得身兼两职：一边看实现，一边猜方向对不对。大多数时候，方向验证是静默失败的。审查者不知道那堆乘除是修 bug 留下来的，点了 approve ，坑就回来了。

这个问题靠更好的 prompt 解决不了，靠更大的上下文窗口解决不了，靠更强的模型也解决不了。

这是一个结构性问题：团队踩过的坑住在哪里？

现在它住在人的脑子里、Slack 里、PR 描述里——Agent 不会主动去看的地方。

要让 AI 真正能在一个有历史的代码库里可靠地工作，我们需要把这些知识搬到它会可靠地去看的地方。对大多数团队来说，那就是 git 。

我们有代码审查。我们需要意图审查。

---

你们有没有被 Agent 悄悄还原过某个 bug 修复？现在是怎么防的？

看看我们的图哈，用在自己产品上的，每个意图都可以追踪、review：

产品已经开源： https://github.com/mainline-org/mainline

好的注释当然要写。局部 invariant、边界条件、奇怪实现，都应该写清楚。

但注释很难承担 repo-level intent：

• agent 可能还没打开那个文件，就已经定了改动计划；
• 决策可能跨服务、跨发布步骤、跨客户迁移窗口；
• 被放弃的方案，往往已经不在当前代码里；
• 注释很难告诉你另一个 agent 正在做什么；
• 注释过期以后，很难看出它是否仍然有效；

reviewer 需要在看 diff 前看到意图，而不是在 diff 里猜意图。 Mainline 不赌下一次 agent 一定会读到正确注释。它把这些事实变成可检索、可 review、可协作的 intent layer。

[DT37]

写的真不错！现在都粗过，信任 测试。

[huoru]

@DT37 那你是怎么处理的啊

[DT37]

@ChristopherWu 不好意思，是我表达问题，我现在也是都走测试。如果测试通过就觉得 OK 了（不能完全信任测试），其实也存在各种没有预料到的问题，粗过是看代码逻辑。

[kneo]

别说 AI 了，这种代码你换个同事一样给你优化掉。你以为你的同事，那位“工作了五六年的老工程师”，真像你想象的那么优秀？

当时的 fix 就是块狗皮膏药，我看不像是 AI 写的，倒像那位“工作了五六点老工程师”写的。

有空让 AI 帮你在假装反思不如认真向 AI 请教下如何正确 fix 这个问题。

[huoru]

@kneo 是啊，就应该让 Ai 去修，带上更多上下文

[freemoon]

其实还是测试的问题，你都修复过了，为何还没有完善测试用例呢

[allanwell]

修改后不更新到 Claude.md 吗？

[huoru]

@allanwell 开发懒啊。。有时 agent 自己有内存记忆了
现在都没规范，而且很多问题总不能全放 claude.md 里吧

[loryyang]

这个有几个思路：
1. 单测回归
2. changelog
另外，人 + AI 混合编码反而更容易造成混乱，因为人很多事情不留文档

[huoru]

@loryyang AI 也不太行。。随时大小便留下文档，留下了就是一堆，相当于没有文档。。

[JYii]

这不是 AI 写了烂代码

只要是做金融相关，都知道金额不可能简单处理，有单独工具处理。AI 拉屎为什么不承认，而且还拉了两次，一定规模公司，今年绩效早没了

[aureole999]

你这文章不是 ai 写的段子？金额相关的用整数大整数不应该是常识么。claude 也不会犯这种错误

[JZen]

遇过类似的问题，项目遇到一个坑，开了一个 session 让 AI 修了好久才修好。
后面开新 session 做新功能时，AI 又踩到这个坑了，又要回去找原来的 session 把坑填回去。
现在我是针对某个模块专门写开发文档，把这个模块的坑记录上，以后 AI 要改这个模块就读一下这个文档，并且把新的坑记录上。

[guidao]

修了 bug ，没补测试呀。看来 AI 时代还是需要测试驱动。

[huoru]

@JZen 试试 mainline ，agent 自动记录到 git notes ，而且会同步到项目以及同事上。就不用再维护文档了

[elehayym1618]

补单测啊，修复的 bug 为什么没有单元测试的覆盖，没有单元测试覆盖的 bug 修复你修了也等于没有修

[cowcomic]

我的经验是这类问题要留注释
这属于关键注释，就算不给 AI 看，没注释人看也迷糊，翻 gitlog 太麻烦

[cocong]

现在的 AI 是概率模型，随着时间的积累，错误只会越来越多，终究是离不开人。

[winnerczwx]

这种问题如果你当时把方案给 AI 让他根据方案修, 它大概率会把价格计算抽成一个公用方法, 需要计算价格的地方全部调这个方法.

重点来了, 你需要在这个公用方法上明确写明注释(你可以自己写, 也可以让 AI 写), 这个地方的改动是为了修复 xxx bug

后续 AI 读到这边大概率就不会乱改了.

[BenHunDun]

好奇，是否可以封装函数成为工具类， 和针对这个问题，能够有够多的测试用例完成覆盖？

[iugo]

"用户账单偶尔会出现 ¥0.01 的误差。复现不稳定，线上偶发，客服一直在手动补差价。" 将这句话喂给 AI, 我相信只需要几分钟 AI 就可以定位问题.

后续的问题, 也和 Agent 有关, 如果 Agent 稍微聪明一点, 或者 MCP 好用一些, 应该通过 git 历史定为到这个修改, 并且结合 git commit message 理解意图, 不需要我们特地说.

[kloge]

写的真好
(另外单测也覆盖不到 amount * 100 这种粒度吧...)

[muzig]

我觉得“补测试”是必要但还不够，金额这种坑最好再往代码结构里沉一层，比如 Money value object / 统一计算 API / lint 或 review rule 。这样历史意图不只是写在文档里，而是变成调用方绕不过去的约束。Agent 看到一堆 *100 / /100 容易觉得啰嗦，但如果入口类型和测试一起约束住，它想“简化”回 float 的成本就高很多。

[yyysuo]

@iugo 同意，喂给 ai 100 个这样的坑，这代码也别改了，ai 顺利继承了人类程序员写屎山的技能。

[huoru]

@iugo 是的，现在 agent 都不太会这个，除非特意说明。 所以我们后来根据这些问题做了 mainline 。

我理解为 AI 时代的 git ， 让 agent 跟人使用的，关注意图，而不是关注代码

Ai 改代码之前永远先看意图，之后更新代码也更新意图（对人手动挡来说也一样）

[chairuosen]

写注释

[paceewang1]

如果是程序里普遍出现的 bug ，就放 rule 里，如果不是，这一行要加上注解为什么要这么写，应该后续就不会被改掉了

[nomansky]

感觉就是软件工程管理的问题，单元测试 corner case 没有测到。

[cookii]

这是 ai 的问题吗，这不是你们方案的问题？谁家用浮点数算钱？

[paceewang1]

@paceewang1 #26 就好像，开源项目的 bug fix ，也是要注解标明为什么要这么干，然后再贴一个具体 bug 的 issue 说明问题吧

[quietnode]

现在主要用 cursor ，这种情况目前我都是在项目中 doc 文档啦下 加一个类似于 ai-必看，然后 rule 指定了这个文件

[mywaiting]

与钱相关的坑，包括但不限于浮点数、币种、汇率转换、金额显示方式等等

也包含数据库事务处理上的扣款、退款、退款队列操作等等

都有很多现成的、经过实战检验的、无数人踩过的坑后，用真金白银堆出的“最佳实践”，准确来说，不能说最佳，应该用行业军规

为什么不重写为独立的 package/interface 去统一处理？

为什么要搞这些莫名其妙的、自以为已经解决问题的修补方式？

实在难以理解

[banricho]

我感觉还是你们的问题比较大，这种东西本来就应该抽象出来单独处理，而不是分散在业务中
如果自己都没办法做到逻辑收束，ai 只会跟着一起摆烂

[guanzhangzhang]

虽然下面对 ai 的看法是对的，但是你这个例子不对，这种涉及到金额的必须写单元测试避免出现回退

[HENQIGUAI]

抛开你的推广不谈，这就是架构设计上的问题

[exonuclease]

谁家好人存财务相关的数据不用 decimal 啊 还要自己发明奇怪方案 这也要怪 AI 吗。。。
而且你修 bug 的时候为啥不加新的 test case 来覆盖这种情况？

[vonfry]

> 0.1 + 0.2 在 IEEE 754 里不等于 0.3 ，这个大家都听说过，但真的踩到还是很痛。
虽然但是，这么多楼居然没人提定点数。涉及金融用定点数是常识吧？怎么会用浮点数来计算啊。

> 修复方案是把所有金额改成以「分」为单位存整数，展示时再除以 100 。改动不复杂，但涉及的地方很多，改完之后代码里到处是 amount * 100 、Math.round()、/ 100 ，看起来有点丑，但能用，bug 消失了。
这个看业务，以分为单位存其实也并不好，比较好的是以“基点”（变动的最小单位）。不过你们的业务可能不需要这么高的精度就是了。

[jchnxu]

@cowcomic 俺也是这个思路

[justdoitzZ]

我之前遇到情况，在算力紧张的平台，通过对浮点型进行方法，转换为整型计算，以节约资源。就间接解决了你说的这个问题。

不过，确实,AI 缺少和真实世界的互动，缺少真实世界的经验，而这些经验，我推测 AI 大厂都在疯狂的收集用户数据来积累。

我每次解决完此类问题，都是让 AI 总结，形成 md 格式的项目经验文档，放到项目根目录，然后后面就可以访问到了。不知道你这个软件有什么差异。

很多人现在都不看代码了，但是在敏感和高风险领域，每一个 AI 修改每一处代码，都需要仔细 review 。比如我的工业生产领域，AI 修改的代码，我都会手动复制到真正的生产代码里面，然后进行仔细的测试，才能上线

[6ugman]

犯这种错误的团队为什么还不被开掉

[Coverlove]

敲代码的时候习惯使用 Comment Anchors 各种添加 //ANCHOR - //NOTE - ...
尤其是修改别人的代码，得先理解，再动手

[thrinity]

我习惯让 agent 修改前看看这个块区域的 git 历史，了解清楚前因后果再落笔。

[huoru]

@justdoitzZ 你说的非常对，最好就是 AI 留痕，持续整理。问题是文档不跟代码走，所以我们做了意图绑定 commit ，从而也跟代码绑定了

之后就不会有文档孵化的问题了

[hubianluanma]

目前我们项目的做法是对于这种错误完善 ut ，每次 AI 在改完后进行测试，随着 ut 的完善，重现 bug 的概率也会降低，还有就是建立 bug 库，通过关键词或者指定的方式进行辅助

[cvbnt]

我个人认为涉及高精度数字计算应该要专门出个工具类来处理，再不济也有现成的依赖可以用

[huoru]

@Coverlove 人的好习惯👍

[villivateur]

所以，我只用 AI 做代码审查，但是不让他直接改。就算改了，每一行也要人工确认。

[ca2oh4]

用 claude code 和他强调做什么不做什么，写清楚项目规则，基本上 ai 不会犯一样的错误了

[xiaomushen]

别听那些自媒体和大 V ，搞许愿池

[justdoitzZ]

@huoru #43 仔细看了你的网站，所以你们想做的是管理经验。好像对大型项目，多人工作的团队更有帮助，对个人开发者，小项目，其实 markdown 文档也够用了。还有一点建议，建议增加演示使用的视频或者动图，我大概弄懂了你想干嘛，但是没太懂，如何实现，如何高效保存来跟随项目的。

[dtdths1]

不是。。这种问题在项目一开始设计的时候都不应该存在。。而且你说单元测试全过，只能说你们单元测试有跟没有没啥区别

[huoru]

review 时，点开一个 intent ，详情是这样子的： https://imgur.com/a/mImqF4R

会跟 git commit 绑定一起，agent 自动填写的

[xuanbg]

不是。。。用浮点数处理金额，你们怎么敢的

[huoru]

@justdoitzZ 是的～，我们接下来会更新说明文档。现在做得太 geek 了，就觉得很有必要做这个工具自己用

[Linczh]

@guidao #14
这个是正解，修 bug 要补充测试，不然后续必然会在重构重丢失这个 bug 的上下文，，，一般这种明显奇怪的写法也要留注释，通常会留下一个 issue#xxx 的标记，还是工程实践没做好

[justdoitzZ]

@huoru #54 已经很牛逼了。网站风格我很喜欢，文档也写得不错。棒棒哒！！！！

[4seasons]

我现在一般较大的改动，都会先生成 spec ，这样它后面改动就知道前面干了什么事情了

[huoru]

@justdoitzZ 感谢，希望对你有用啊。Solo 开发也能用上的，起码直观看到 ai 做了啥

[Cruzz]

整个项目给他让他改，你是真敢啊

[SD10]

写的真好 有机会尝试一下

我现在很少看 AI 修改的代码了，对代码的理解完全就是一团浆糊，主要还是小公司路子太野了，曾经吹牛皮一天一个版本，鼓励的就是人不要再看了... 摆烂中

[huoru]

@SD10 感谢。是啊，最起码看看 意图。。我理解大家都越来越不能去看代码了

[ovtfkw]

所以其实是虚构的故事＋软广？

[x1aoYao]

@ovtfkw 百分百编故事的，搞金融的还需要排查才知道钱不能用浮点数？大学生都没这么水吧

[catoncat]

@ovtfkw #62
@x1aoYao #63 是虚构的，不过 mainline 的代码确实是用 mainline “自举”开发出来的。clone 下来使用 mainline hub open 可以打开网页看到 mainline 项目自己所有的历史 intent 和详情。
这个故事确实有点太简单了。只是为了便于用户理解。包括现在的 mainline.sh 也是苦于不知道怎么设计比较好传达项目的用途。

[jydeng]

写的是不错，不过「金额不用浮点数」应该是个常识，人和 AI 都有问题。

[402124773]

你能不能正面回复下这个问题，是不是为了推广，编造的上面的故事？

[loryyang]

@huoru #10 那只是你没给他规定而已。如果只说一句： 开发完成写 changelog ，那当然会随便乱写。你至少要写：”什么时候，在什么地方，写入什么文件名，内容包括*****，文件长度不可超过多少行“
模型能力你说指令完全遵从确实不行，但在哪里写文档，什么时候写基本上还是做得到的

[xing7673]

移到推广节点

[EeveeRibbon]

@Livid @Kai @Olivia @GordianZ @sparanoid @drymonfidelia @GordianZ @sillydaddy 软广

[idealhs]

恶心人编故事，人和 AI 都不会写出这种 bug 现在打开 V2 全是 AI 写的 AI 推广文，真没什么好看的了

[catoncat]

@loryyang #67 主要是文档会腐化，有比较高的维护成本，多人协作时也会有类似代码冲突一样的决策冲突问题。这个工具主要还是参考 git 提供一个可以多人统一的工作流。
你说的正好是这个工具提供的 intent 的数据结构之一，就是记录下约束。后面 agent 有新的 intent 要开发是会根据文件自动看到这些上下文。

[zhuzhibin]

这不是卖广告？前面铺垫了这么多

[legendBro]

金融用浮点数？难道不是用精准计算的方法，比如 java 里的 BigDecimal ？

[huoru]

@zhuzhibin story telling 啊。

[huoru]

@zhuzhibin 分享事情啊。纯技术的角度，我分享过了： https://www.v2ex.com/t/1210451

[kamilic]

你这种不就是一个变种知识库或者是记忆模块 😂
按照古法编程这种敏感数字操作就应该转用成熟且久经考验的公共库，又或者是自研经过测试的库。再进一步，围绕这种场景建立一堆规范和 lint ，以及 CI/CD 单元测试来挡着。而不是搞个东西让 ai 记得，万一你的这个坑召回不了呢，不也是照样踩进去了？
人和 AI 都会出错的，只是 AI 上下文大一点而已，但是不代表他每次都能百分百准确找出你这边角旮旯里的「意图」并识别出来。

[huoru]

@kamilic 是啊，就是这样子。 那现在所谓的 skill, harness engineering, compound engineering 等等词语，不就是 xxx

AI 总是要出错的，人总是会懒得读代码的，我们只是尽可能适应时代做一个能帮助大家的开源产品，哈哈

[Clannad0708]

那我问个问题，如果你让 ai 写一个新项目他做金额的计算的时候还是会遇到 0.1+0.2 不等于 0.3 的问题吗？

[FlashEcho]

我怀疑是你给了烂 prompt ，现在的 ai 大概率会建议你改用 Decimal 处理钱吧，你看到 Decimal 一下子就能意识到为啥要用，不会出现用分为单位的整数还要想的情况

要么是你的 ai 模型不行，要么是你的 prompt 太差了，这么基础的问题都处理不好，还有人愿意用你开发的新产品吗？

[fennu2333]

感觉有点像 Entire https://github.com/entireio ，只是 Entire 把所有的 Agent Session 都存到 git 了
git 记录这个思路不错，我之前自己做 https://github.com/Chorus-AIDLC/Chorus 的时候也想解决这个问题，但做法是把决策固化到一个单独的服务里去了方便 agent 查询

[Exxfire]

加点注释？ AI 看到注释是不是就不会优化你的补丁了

[huoru]

@fennu2333 我们也看过 entire ， 觉得没什么用。我们要的是上下文，为什么做这个决定，有什么要避免的等等，不是一个完整的 session 。哈哈，要说的话，mainline 也可以链接具体的 session id 的

你这个项目好多人关注啊，怎么宣传的啊

[linxb]

写一些奇奇怪怪的补丁代码，请加点注释

[Livid]

@EeveeRibbon 谢谢，这个主题已经被移动。

[lxqn54]

@cocong 这个怎么解释，求问下

[teaguexiao]

我在真实项目里踩过类似的坑，修完 bug 之后让 AI 在对应的代码块上方写一句解释性注释（不是禁止注意那种，而是「这里改用整数是为了避免 IEEE 754 精度问题，2024-03 实际踩坑过」），后续重构时 AI 会读到上下文，基本不会再「简化」回去。关键是注释要写清楚「为什么」不是「是什么」。

[huoru]

@teaguexiao 厉害了，这种有意识就是能避坑。要是不注意基本就翻车了

[fregie]

这本质上使工程问题，而不是“AI”还是“人”的问题
根本原因：踩坑后没有增加单测覆盖对应场景，甚至连注释都没加

[bowencool]

"单元测试全过"

你都修完 bug 了，测试用例不改，你活该呀！！！！

[bowencool]

而且金额怎么可以用浮点数呢？你是大学生吗？这点常识都没有？

[qianlifeng]

以前都提倡少写注释, 代码命名清晰就行. 现在变了, 我是让 AI 多写注释, 反正也不是给我看的, 后面 AI 再改动任何地方的时候有了注释也就有了更加清晰的上下文, 知道当时为什么这么改.

[huoru]

@qianlifeng 是的，但也有上下文限制以及注意力的问题。而且 grep 、sed 也不够准确

[yufeng0681]

@freemoon #6 测试发现了问题，也属于事后了。op 表达的意思应该是事前要做到位，不要产生无畏的劳动，蛮消耗 token 的

[huoru]

@yufeng0681 你总结得太好了😉

[mangoDB]

楼主，说实话，相较于你着重强调的“AI 引入 bug”这一问题，我更为震惊的是，在你们的业务场景中，涉及“金融及金额的小数运算”时，竟然直接采用了浮点数进行计算。

上大学时，我们应该都学过浮点精度问题。尤其在刷一些 OJ 题目时，一旦涉及浮点数运算比较大小，就需要自己定义一个精度然后做差判断。

[huoru]

@mangoDB 很多人没这个基础知识啊。。🤣不是所有人都是科班出身的，也有 PM 转代码的。。

[aureole999]

@huoru 系统设计 db 设计到实现上线整个流程没一个科班的？你直接让 ai 设计一个保存账单的表 ai 都会提到不要用 float double

[esee]

我一直以为这是个常识，涉及到金钱的计算都用分来存储和计算，即使没有，对接一次阿里和 tx 的支付接口应该都会有经验。

[loggerhead]

感谢 OP 分享，最近在思考相同的问题，OP 的想法蛮有启发的。给个小建议，可以补一个 mainline 的演示 gif 或简单的讲一下完整的工作流程。我读完全文没理解它是怎么做到 [意图审查] 的，比如需要人工喂入意图吗？还是它会起一个 agent 周期性的总结整理意图？

[irisdev]

我不信，这么简单的问题线上这么久没人想到问题在哪