agent-code-health-demo:这是一个有bug的项目用于检测 - AtomGit一键开通华为云码道 CodeArts 代码智能体 Developer Events_Developer Alliance-Huawei Cloud一、前言最近在体验 AI 编程工具时我发现一个比较有意思的问题如果直接让 AI 从零生成一个项目我们很容易看到它“会不会写代码”但却很难判断它是否真正具备处理真实项目的能力。因为在实际开发过程中我们面对的往往并不是一张白纸。更多时候项目已经存在开发者需要处理的是已有代码中的 Bug功能逻辑异常用户输入校验不足潜在安全风险移动端适配问题历史代码维护Issue 跟踪Pull RequestCode Review。所以这一次我没有继续测试“AI 能不能从零写一个网页”。而是反过来做了一个实验故意准备一个存在问题的小型 Web 项目然后把整个项目交给 AtomGit Agent让 AI 从项目分析开始完成问题定位、Issue 整理、代码修复、测试验证、Pull Request再结合 AI Code Review 对修改结果进行二次检查。整个过程可以概括为已有项目 ↓ AI 项目体检 ↓ 问题定位 ↓ Issue 管理 ↓ 制定修复计划 ↓ 代码修改 ↓ 回归测试 ↓ Pull Request ↓ AI Code Review ↓ 二次修复 ↓ 最终确认这一次想测试的已经不是简单的“代码生成能力”而是AI Agent 能不能真正参与一次软件项目维护流程二、实验项目FocusBoard 任务管理面板为了让实验更加直观我准备了一个非常简单的 Web 项目FocusBoard——个人任务管理面板。项目采用 HTML、CSS 和 JavaScript 实现不需要复杂的后端环境直接打开index.html即可运行。项目主要包含以下功能添加任务删除任务完成任务取消完成按任务状态筛选统计任务数量LocalStorage 数据保存移动端基础适配。项目本身并不复杂。但是这次实验的重点并不是项目有多复杂而是我故意在其中保留了一些问题。这些问题包括删除任务后统计数据不能及时同步用户可以提交空任务LocalStorage 初始化逻辑存在进一步优化空间用户输入直接进入innerHTML存在潜在安全风险极窄屏幕下任务操作区域仍存在优化空间。这样设计的好处是如果直接告诉 AI 问题在哪里它只需要执行修改。而如果让 AI 自己检查项目就可以更加直观地观察它的项目理解能力。三、第一步把项目交给 AtomGit Agent项目上传到 AtomGit 后我首先进入 Agent 工作页面并关联刚刚创建的项目仓库。这里我没有立即让 Agent 修改代码。第一条指令只有一个目的先让 AI 看懂项目。我输入请先不要修改任何代码。 请把当前仓库当成一个刚刚接手的真实项目 完整分析这个项目的结构、功能和代码实现。 请重点检查 1. 项目整体结构是否合理 2. 任务新增、删除、完成、筛选功能是否存在逻辑问题 3. 页面统计数据是否能够与任务状态保持同步 4. 用户输入是否进行了必要校验 5. LocalStorage 数据读写是否存在问题 6. 是否存在潜在的安全风险 7. HTML、CSS、JavaScript 是否存在明显的代码质量问题 8. 移动端是否存在明显的界面适配问题。 请先输出一份详细的《项目体检报告》。 对于每个发现的问题请说明 - 问题名称 - 严重程度 - 涉及文件 - 具体原因 - 可能造成的影响 - 建议解决方案 特别注意 现在只允许分析不要修改任何文件 也不要创建新的代码文件。 等我确认之后再进行下一步。这一步的核心思想非常简单先诊断再治疗。从实际过程来看Agent 会先围绕项目结构和代码逻辑进行分析而不是立即给出一段全新的代码。对于一个已经存在的项目而言这一步非常重要。因为如果连项目结构都没有理解清楚后面的修改就很容易变成“头痛医头脚痛医脚”。四、第二步让 AI 把代码问题转化成 Issue发现问题以后我没有直接让 Agent 修改所有代码。而是进一步要求它把发现的问题转化成可以管理的开发任务。输入请根据刚才的项目体检结果 将确认需要处理的问题整理为 AtomGit Issue。 要求 1. 每一个相对独立的问题建立一个 Issue 2. Issue 标题必须清晰、简洁 3. Issue 描述需要包含 - 问题背景 - 复现步骤 - 实际表现 - 预期表现 - 影响范围 - 建议解决方向 - 验证标准 4. 不要创建重复 Issue 5. 请优先创建真正影响功能正确性或安全性的问题 6. 暂时不要修改代码。 创建完成后请列出本次创建的 Issue。这样一来原本散落在 AI 对话中的问题就被转化成了项目中的正式任务。AtomGit 中的 Issue 不只是简单的留言它可以用于 Bug 报告、功能请求和任务管理并可以进一步添加标签、负责人以及关联代码变更。这样做的一个好处是问题不会只存在于某一次聊天记录中而是进入了项目本身的协作流程。五、第三步查看一个真实 Issue以“删除任务后统计数据未同步更新”为例。这个问题的现象很简单删除任务之后任务列表确实发生了变化但是顶部统计数字没有立即同步。这样做以后一个原本只有几行代码的问题就具备了完整的问题 ↓ 复现方法 ↓ 预期结果 ↓ 影响范围 ↓ 修复标准后续无论是自己修改还是交给其他开发者处理都更加清晰。六、第四步让 Agent 先制定修复计划接下来我仍然没有让 Agent 直接修改全部代码。而是要求它现在请基于刚才创建的 Issue 制定本次项目的修复计划。 要求 1. 优先处理影响功能正确性的高优先级问题 2. 分析不同问题之间是否存在依赖关系 3. 明确每个问题需要修改的文件 4. 明确每个问题修改后的验证方法 5. 每次修改尽量保持范围最小 6. 不要一次性重写整个项目 7. 暂时不要执行代码修改。 请按照“问题 → 原因 → 修改位置 → 修改方案 → 验证方法”的格式输出。这一步看起来似乎有些“多余”但实际上非常重要。如果一开始就让 AI“把所有 Bug 全部修掉。”那么我们很难知道它到底修改了哪些内容。而现在采用问题 ↓ 分析 ↓ 方案 ↓ 修改 ↓ 验证的方式每一步都更加容易追踪。七、第五步让 Agent 修复第一个 Bug首先处理删除任务后统计数据未同步。输入现在开始处理第一个高优先级问题 “删除任务后统计数据未同步更新”。 请严格按照以下要求执行 1. 先检查当前实现 2. 确认问题原因 3. 只修改解决该问题所需要的代码 4. 不要重写整个项目 5. 不要修改与本问题无关的功能 6. 修改完成后进行自检 7. 告诉我具体修改了哪些文件 8. 说明修改前后的逻辑区别 9. 给出验证步骤。 如果发现其他问题请记录下来 不要顺便修改其他问题。原来的删除逻辑在删除任务之后刷新了任务列表却没有同步更新统计数据。Agent 如果定位正确最终需要让删除操作完成以后统计数据也重新计算。八、第六步修复空任务问题第二个问题是用户输入校验。输入现在处理第二个问题 “任务输入缺少有效性校验”。 要求 1. 检查任务新增逻辑 2. 对用户输入进行必要的空白处理 3. 空输入和只包含空格的输入不能创建任务 4. 不影响正常任务创建 5. 修改后进行测试 6. 说明修改位置和验证结果。 不要修改其他无关功能。这里主要是让 Agent 处理类似const title taskInput.value;这样的输入逻辑。合理的实现应该首先处理用户输入再判断内容是否有效。这一类问题看起来很小但在实际项目中非常常见。如果一个表单没有进行最基本的输入校验最终很容易出现大量无意义数据。九、第七步让 AI 主动检查潜在安全风险这一部分是我认为本次实验比较有价值的地方。我没有直接告诉 Agent“这里存在 XSS。”而是让它自己检查任务标题的渲染方式现在检查并处理任务标题渲染相关的安全问题。 重点检查 当前任务标题是否直接进入 innerHTML。 请分析这种实现是否存在潜在安全风险。 如果存在请采用尽量简单、可维护的方式进行修复 确保用户输入不会被当成 HTML 或脚本执行。 要求 1. 不破坏正常中文和特殊字符显示 2. 不影响任务删除和完成状态 3. 修改后说明安全风险的来源 4. 给出修复后的验证方法。原来的代码中用户输入的任务标题直接参与 HTML 字符串拼接。这类写法在实际开发中需要谨慎处理因为用户输入不应该在没有适当处理的情况下直接作为 HTML 插入页面。相比简单的 UI 生成这一步更加接近真实项目维护AI 不只是根据需求写代码还需要主动发现已有代码中的风险。十、我为什么没有让 Agent 一次性重写整个项目这是这次实验中我比较坚持的一点。实际的软件开发中Bug 修复最忌讳“为了修一个问题把整个项目重新写一遍”。所以我一直要求 Agent只修改必要代码 不要重写整个项目 不要修改无关功能这样做有三个好处。第一修改范围更加清晰。第二出现问题以后更容易定位。第三后续进行 Pull Request Review 时可以更加准确地判断每一次修改的意义。因此我更倾向于把 AI Agent 当成一个能够执行开发任务的工程助手而不是一个每次都从零生成代码的代码生成器。十一、第八步让 Agent 进行回归测试代码修改完成以后并不能直接认为项目已经修好了。所以我又给 Agent 一个完整的回归测试任务现在请对当前项目进行一次完整回归检查。 不要继续增加新功能。 请重点验证 1. 添加正常任务 2. 添加空任务 3. 添加只有空格的任务 4. 完成任务 5. 取消完成任务 6. 删除任务 7. 连续删除多个任务 8. 切换全部/进行中/已完成 9. 刷新页面后检查数据 10. 检查任务统计数据 11. 检查任务标题中的特殊字符 12. 检查移动端页面。 请输出 - 已验证项目 - 验证结果 - 发现的问题 - 是否建议进入 Pull Request 阶段输出#检查项结果说明1添加正常任务✅学习 Node.js创建成功统计 2→32添加空任务✅弹窗任务内容不能为空不创建3添加纯空格任务✅同上被拦截4完成任务✅已完成 1→2进行中 1→2标题加删除线样式5取消完成任务✅已完成 2→1状态恢复6删除任务✅任务移除统计同步减 17连续删除多个任务✅删空后统计 0/0/0空状态提示显示8切换全部/进行中/已完成✅进行中 2 条、已完成 1 条、全部 3 条按钮高亮正确9刷新页面数据保留✅reload 后 3 条任务、状态与统计完整保留10统计数据一致性✅total active completed与列表条数一致11任务标题中的特殊字符❌存在存储型 XSS脚本已实测执行12移动端适配✅375px 无水平溢出统计单列、toolbar/form/header 纵向堆叠、按钮全宽这里的核心思想是修改代码 ≠ 完成任务真正完整的开发流程应该是修改 ↓ 测试 ↓ 发现问题 ↓ 再次修改 ↓ 重新测试十二、第九步创建 Pull Request完成修复以后我没有直接把代码合并到主分支。而是把修改整理成 Pull Request。建议 PR 标题fix: 修复任务统计、输入校验与任务渲染安全问题PR 描述## 修改背景 本次 PR 用于修复 FocusBoard 任务管理面板在任务删除、 用户输入和任务标题渲染方面存在的问题。 ## 主要修改 1. 修复删除任务后统计数据未同步更新的问题 2. 增加任务输入有效性校验 3. 优化任务标题渲染方式避免用户输入直接作为 HTML 插入 4. 对相关逻辑进行回归验证。 ## 测试内容 - 添加正常任务 - 添加空任务 - 添加空格任务 - 完成/取消完成任务 - 删除任务 - 连续删除任务 - 切换任务筛选状态 - 刷新页面 - 检查特殊字符显示 ## 关联问题 关联本次修复对应的 Issue。到这里一个完整的Issue ↓ 代码修改 ↓ 测试 ↓ Pull Request链路就已经形成了。十三、第十步让 AI 再检查一次 Pull Request接下来进入 AtomGit 的 AI Code Review 环节。这里和前面的 Agent 项目分析有所不同。前面是让 Agent 理解整个项目并执行修复。现在则是针对已经提交的 Pull Request 进行代码审查。AtomGit 当前的 AI Code Review 能力支持从正确性、安全性、性能、可读性和代码风格等多个维度检查代码变更并支持在 PR 评论区通过/ai review触发 Review。如果自动 Review 没有触发可以在 PR 评论区输入/ai review等待 Review 完成。这一步是整个实验比较有意思的地方。因为现在出现了一个新的角色开发 Agent ↓ 修改代码 AI Code Review ↓ 重新检查代码也就是说一个 AI 负责执行修改另一个 AI Review 环节负责重新检查修改结果。十四、如果 AI Review 又发现问题怎么办如果 Review 发现新的问题不应该为了让页面显示“通过”就强行修改。我会把 Review 内容再次交给 AgentAI Code Review 刚刚发现了一个问题 【将实际 Review 内容粘贴到这里】 请先判断这个问题是否真实存在。 如果确认存在 1. 分析问题原因 2. 修改必要代码 3. 不要扩大修改范围 4. 完成后进行回归验证 5. 更新当前 Pull Request 6. 告诉我本次问题是如何解决的。 如果你认为这是误报请说明判断依据 不要为了通过 Review 而强行修改代码。这一步其实非常重要。因为 AI 的作用并不是“永远说自己是对的。”而应该是发现问题 → 判断问题 → 根据证据决定是否修改。十五、最终再次 Review完成二次修改以后再次执行/ai review确认修改后的 PR。如果最终没有发现需要继续处理的问题那么整个实验就形成了完整闭环项目体检 ↓ 发现问题 ↓ Issue ↓ 修复方案 ↓ 代码修改 ↓ 回归测试 ↓ Pull Request ↓ AI Code Review ↓ 二次修复 ↓ 最终 Review十六、这次实验到底有什么不同如果只是让 AI 从零生成一个网页那么整个过程可能只是需求 ↓ AI ↓ 代码 ↓ 运行而这次实验变成了已有项目 ↓ AI 分析 ↓ 发现问题 ↓ Issue ↓ 任务拆解 ↓ 代码修改 ↓ 测试 ↓ Pull Request ↓ Code Review ↓ 再次修改两者最大的区别并不是AI 写代码速度更快。而是AI 开始参与整个软件工程流程。十七、从“代码生成”到“项目维护”通过这次实验我对 AI 编程有了一个比较明显的感受。以前使用 AI 时我们经常问“这段代码怎么写”或者“这个功能怎么实现”这属于典型的代码生成场景。但是当 Agent 可以直接面对一个完整的代码仓库以后问题会逐渐变成“这个项目有什么问题”“哪些问题优先级更高”“应该修改哪些文件”“修改之后是否影响原有功能”“这个 Pull Request 有没有潜在风险”这时候 AI 的工作对象已经不再是一段代码而是一个完整的软件项目。十八、这次实验中我认为最值得关注的三个点1. AI 不再面对一张白纸这次给 Agent 的不是一个空项目而是一个已经存在的项目。这意味着它必须先理解目录、代码、数据、状态、功能、模块之间的关系再开始工作。2. Issue 和 PR 把 AI 的工作变得可追踪如果所有工作都发生在聊天窗口中那么几天以后可能很难知道“AI 到底改了什么”但是通过Issue Commit Pull Request Code Review整个过程就可以留下清晰记录。这也是软件工程协作中非常重要的一部分。3. AI Review 让“AI 修改 AI 检查”成为可能这次实验最让我感兴趣的地方是最后形成了Agent 负责修改 ↓ AI Code Review 负责检查 ↓ Agent 根据反馈继续修改这并不意味着 AI 可以完全替代开发者。恰恰相反开发者仍然需要负责需求判断、风险判断和最终决策。AI 更适合承担大量重复性的分析、搜索、修改和检查工作。十九、完整实验流程图如果把这次实验浓缩成一张图可以表示为┌───────────────┐ │ 已有项目 └───────┬───────┘ ↓ ┌───────────────┐ │ Agent 项目体检 └───────┬───────┘ ↓ ┌───────────────┐ │ 问题定位 └───────┬───────┘ ↓ ┌───────────────┐ │ 创建 Issue └───────┬───────┘ ↓ ┌───────────────┐ │ 制定修复计划 └───────┬───────┘ ↓ ┌───────────────┐ │ Agent 修复 └───────┬───────┘ ↓ ┌───────────────┐ │ 回归测试 └───────┬───────┘ ↓ ┌───────────────┐ │ Pull Request └───────┬───────┘ ↓ ┌───────────────┐ │ AI Code Review └───────┬───────┘ ↓ 是否存在问题 ↙ ↘ 是 否 ↓ ↓ 再次修复 完成 ↓ 再次 Review二十、总结这次实验最开始我只是准备了一个很普通的任务管理网页。但真正把项目交给 AtomGit Agent 以后我发现测试 AI 编程能力的方式其实可以完全不同。我们不一定非要问“AI 能不能帮我写一个项目”还可以换成“如果给 AI 一个已经存在的问题项目它能不能帮我把这个项目维护下去”在这次实验中整个流程从项目分析开始经过Issue→修复→测试→Pull Request→AI Code Review→二次修复最后重新回到Review形成了一个完整的软件工程闭环。我认为这种使用方式比单纯让 AI 生成一段代码更值得尝试。因为真实的软件开发本来就不是写完代码就结束。而是需求 → 开发 → 测试 → Review → 修改 → 再验证。当 AI Agent 开始进入这个流程以后AI 编程的角色也可能从单纯的“代码生成工具”逐渐变成一种更加接近“开发协作者”的工作方式。当然AI 输出仍然需要人工验证。尤其是涉及安全、数据、生产环境和重要业务逻辑时不能因为 AI 给出了“已完成”就直接认为结果一定正确。真正合理的方式不是把开发者排除在流程之外而是让 AI 承担更多重复工作让开发者把精力集中在需求、架构、验证和最终决策上。这也是我这次使用 AtomGit Agent 做这个小实验之后最大的感受。