第一件小事：几年前我写过一篇名为《测试覆盖率治不好你的精神内耗》的文章，想表达是盲目的追求高测试覆盖率并不明智。例如在JavaScript中使用zustand框架创建store的声明基本上都遵循如下模式：
export const useUIStore = create(persist((set) => ({ property: false, setPropertyValue: (value) => set({property: value }),})这种模式在我的项目中重复了11次，为了追求测试覆盖率，相似的测试代码也不得不重复在测试文件中出现了11次，这完全是没有必要的。除了冗余代码之外，测试代码的性价比也是另一个问题，在提升测试覆盖率的过程中，绝大部分的新增测试代码其实是用于覆盖边缘场景，然而使用实际使用产品的过中有多大概率会触发这类边缘场景呢？成倍投入时间的结果真的是bug在成倍减少吗？
第二件小事：在《整洁架构》一书中，鲍勃马丁对注释的态度算不上欢迎。注释本身就代表着一类“失败”——“噢，也许这段代码过于复杂，我应该用注释解释一下”——通常这只会让情况更糟，要知道写出好的文字说明不比写出好的代码简单，人们总是懒得在编写注释上投入时间，注释也总是在代码更迭中被疏于维护。在这些条件下被糟糕“照料”的注释所产生的负面效果远比正面效应要大，它们会给人带来误导，让人费解——最好的注释其实是代码本身：带有少量注释的整洁而有表达力的代码，要比带有大量注释的零碎而复杂的代码像样的多。所以一般在编码的过程中，我们其实并不鼓励给代码添加注释，优先把代码写好就足够了。
说到底，驱动我们给出如上结论的动力不是我们不具备这种能力，而是我们觉得把它们做好的性价比不高。如维护文档、写端到端测试、补全注释等等，没有人能算得清我们需要投入多少而它们又能换回来多少回报。团队不愿意做看不到目标而又遥遥无期的事情，程序员本身也反感这类琐碎而又没有挑战工作。
而现在AI可以帮助我们完成这些琐碎的工作，这也是最近我在维护的我的个人AI工具时所尝试的实践，它们简单有效。
多快好省的Agent
以Cursor为例，迫使AI能够实时更新文档最简单粗暴的方式其实是通过Cursor Rules。Cursor rules是cursor编辑器的自有功能，它允许我们为项目定制代码的生成规则或者应该遵守的规范，Cursor rule通常定义在以.mdc为扩展的文件中，并保存在项目根目录的.cursor/rules 目录下，例如：
---description: React Components Rulesglobs: *.jsxalwaysApply: true---- When you completed coding the component, generate a document file to describe the usage of the component
该流水线运行分为两类步骤，首先安装Git、Cursor CLI以及GitHub CLI:
- name: Install Cursor CLI run: | curl https://cursor.com/install -fsS | bash echo "$HOME/.cursor/bin" >> $GITHUB_PATH- name: Configure git run: | git config user.name "Cursor Agent" git config user.email ""- name: Authenticate GitHub CLI run: | echo "$" | gh auth login --with-token gh auth status最后让cursor agent执行prompt- name: Update docs env: MODEL: gpt-5 CURSOR_API_KEY: $ GH_TOKEN: $ BRANCH_PREFIX: docs run: | cursor-agent -p "You are operating in a GitHub Actions runner. The GitHub CLI is available as `gh` and authenticated via `GH_TOKEN` environment variable. Git is available. You have write access to repository contents and can comment on pull requests, you can also create or edit PRs. # Context: - Repo: $ - Owner: $ - PR Number: $ - Base Ref: $ - Head Ref: $ - Docs Branch Prefix: $ # Goal: - Implement an end-to-end docs update flow driven by incremental changes to the original PR. # Requirements: 1) Determine what changed in the original PR and, if there have been multiple pushes, compute the incremental diffs since the last successful docs update. 2) Update only the relevant docs based on those incremental changes. 3) Maintain the persistent docs branch for this PR head using the Docs Branch Prefix from Context. Create it if missing, update it otherwise, and push changes to origin. 4) If you need to create a new doc, you must follow the same pattern as the existing docs. # Inputs and conventions: - Use `gh pr diff` and git history to detect changes and derive incremental ranges since the last docs update. - Keep changes minimal and consistent with repo style. If no doc updates are necessary, make no changes and post no comment. # Deliverables when updates occur: - Pushed commits to the persistent docs branch for this PR head. - A single natural-language PR comment on the original PR that includes the inline compare link above. Avoid posting duplicates; update a previous bot comment if present. - Create a draft PR from the persistent docs branch to the main branch. - Describe what you observed and what you did to update the docs in detail in the PR description. " --force --model "$MODEL" --output-format=text
在prompt中，我完全没有用自然语言将agent执行任务所需的线性步骤一五一十的描述出来，我仅仅是把诉求以及可用的工具转达给agent，这是和传统编程最大的不同。 在为agent设计该类型的任务时需要有意的设计一个明确的“出口”，这个出口不仅是可以作为agent完成任务的标识，还可以作为开发者介入或者进行审核的信号，而在上述代码中，该“出口”即为另一个创建文档用的PR。
该段prompt 这不是我的原创，这是写在cursor官方使用手册里的一部分，只不过我根据我实际项目的需求对prompt进行了部分的修改——但我相信你已经其中看到其中的潜力。无论是获取上下文还是想要执行Git操作，cursor agent都可以使用间接通过GitHub CLI来达成目标，我们只需要（通过GitHub Token）赋予它权限即可。完整代码请参考auto-update-docs.yml
理论上我们可以用这种模式完成一切我们想要完成的代码任务，比如迫使测试覆盖率提升至100%。
当然这里的测试覆盖率的覆盖范围并不是无限大的，并非指所有在src 目录下的看到的一切代码，而是仅仅包括抽象到store中的核心的业务逻辑和组件状态（如窗口是否隐藏）。这类整洁架构的本质是View（前端组件，React 实现）与 Model（业务逻辑，Zustand 实现）的分层，这样一来前端组件只单向依赖业务逻辑 ，表现层便独立于业务层。无论将来打算迁往 Vue 还是 Angular，还是对React组件进行重构，核心业务逻辑都不用发生变化。
核心代码如下：
- name: Generate Tests for 100% Coverage using Cursor Agent env: CURSOR_API_KEY: $ MODEL: gpt-5 run: | cursor-agent -p "You are operating in a GitHub Actions runner to generate comprehensive stores related test coverage. The GitHub CLI is available as `gh` and is properly authenticated. Git is available. You have write access to repository contents and can comment on pull requests and create PRs. # Context: - Current coverage is below 100% and needs improvement - You can use "npm run test:stores:coverage" to re-generate coverage report for stores again. - Uncovered code analysis has been generated and saved to 'uncovered-analysis.json' - Natural language description saved to 'uncovered-description.md' - Target: Achieve 100% test coverage for store files # Goal: Generate comprehensive unit tests for all uncovered code to achieve 100% test coverage. # Requirements: 1) Read the 'uncovered-analysis.json' file to understand what needs testing 2) For each file with uncovered lines, generate complete test files 3) Refer to the existing test files for patterns and best practices 4) Cover ALL uncovered lines mentioned in the analysis 5) Test every function, method, and code path in the store 6) Use proper mocking for external dependencies and browser APIs 7) Test both happy path and edge cases for each uncovered line 8) Ensure tests are realistic, meaningful, and production-ready 9) Use existing test patterns from the project 10) Import statements should be correct relative to test file location 11) Tests should be well-documented with descriptive names 12) Focus on achieving 100% line, function, and branch coverage 13) You are not allowed to create new files, only modify existing ones # Output: - Modify existing test files for all uncovered code - Ensure 100% coverage is achieved - Pushed commits to the coverage-improvement branch. - Create a draft PR from the coverage-improvement branch to the main branch. - Describe what you observed and what you did to improve the coverage in detail in the PR description. " --force --model "$MODEL" --output-format=text
- I read `uncovered-analysis.json` and identified `src/stores/uiStore.js` line 86 (`state.testModalVisible = visible;`) as uncovered.- I updated `src/tests/stores/uiStore.test.js` to add tests for `setTestModalVisible` and added `testModalVisible` assertions within the `resetUIState` flow.- I ran `npm run test:stores:coverage`; stores now report 100% lines, functions, and branches.- I committed the changes, pushed to `coverage-improvement-20251002-155106`, and opened a draft PR to `master`.PR: https://github.com/hh54188/ai-assistant-chrome-extension/pull/18What I changed:- Added tests for `setTestModalVisible` in `src/tests/stores/uiStore.test.js`- Ensured `resetUIState` resets `testModalVisible` and asserted itCoverage verification:- Stores coverage: 100% (uiStore.js and chatStore.js)
用agent对抗agent
还有第三件小事，它之所以没有在文章的开头和前两件小事摆放在一起，是因为我并不认为它归属于某种实践，而是应该属于某种“默契”。
我工作的过的所有的创业公司以及中型公司都没有代码评审，唯一工作过的大厂内所谓“代码评审”也不过是走个形势：我把PR链接发送给同组的同事，它点击“批准”——只因为这是将代码合并至主分支的必须环节，这让我一度以为所谓的代码评委同于来自于某种“来自于高级工程师的批准”。
我理解为什么大部分公司会无视代码评审，本质上这是种种因素叠加之后妥协的结果。我甚至觉得这也没有什么可惜的，因为从和团队的沟通体验看，我大概可以预见到不太可能得到什么有价值的代码反馈。AI同样改变了这一切，也许你的同事没法给你专业的意见但是AI可以；也许你没有完整读完过《重构》但是AI早已牢记心中。
目前我在项目中集成了Gemini，它会对每一次PR所涉及到的一切改动进行评审，没错，是一切，甚至markdown文档也不会放过。但问题来了，你怎么知道他的建议就是对的？同样的我们可以借助AI，用Cusor来评论Gemini的评论
完整的代码就不在这里展示了，可以访问review-pr-comments.yml来阅读，模式与此前无异，最核心的原理同样是借助CLI来获取上下文以及撰写评论。执行效果如下：
你之所以看到评论者是我的头像而不是Cursor，是因为使用的是我个人access token的缘故。很有意思的是在AI的加持下，任何一个个人项目都不再是“个人”项目：
开发者的如何介入其中
开发者无法成为甩手掌柜，设计、决策都需要开发者的参与。
以补全文档为例，我要的不仅仅是一份文档，而是一份恰到好处嵌入在这个项目中的文档，这对文档的保存位置，其中必须出现的内容以及格式都有特殊的要求。AI直接生成的文档事无巨细并不是一件好事，过载的信息会破坏阅读体验让人读起来更像是噪音。这就是我为什么不能直接照抄cursor官方的prompt语句
同样的对于来自Gemini和Cursor的建议我也不会照单全收，他们给出的建议仅仅基于获得的是它们能够获得的上下文，但问题是并非所有的上下文都被以文档或者代码的方式记录在项目中，它不知道这只是一个side proejct我只会投入有限的时间在其中；它不知道它还根本没有机会被部署到云环境中。
更重要的是在体验中改善。
在上一小节中，我似乎在宣扬某种万能的模式：赋予至高的权限加上万能的工具，cursor agent就可以所向披靡。这只是理论上如此——事实上我还构建一个条用于修复流水线的流水线，它可以获取失败流水线的日志，分析它们并提交修复代码，且再次触发流水线来验证修复结果。但执行的效果并不尽如人意，将日志复制到Cursor编辑器中，哪怕使用Cursor的Background Agent效果都会比流水线更好。
没有什么是万能的，你可以说大部分工具不过的大模型的套壳，但如果你真的体验过这些“壳”，就会发现即使基于的是同一版本的模型，它们适用的场景和能力也各不相同，甚至不同工具对于不同开发者的效用也各不相同。只有你自己才知道你的项目需要什么样的工具，搞清楚的方法离不开亲身尝试。
