AI 编程行为指南：Agent 不担责，PR 控制在 600 行内

AI-assisted programming has advanced at breakneck speed. AI agents such as Claude Code and Codex have become indispensable helpers for many software engineers. Yet when it comes to putting AI programming into practice on a real project, everyone is still doing their own thing — each with their own tricks.

If engineers on the same team never agree on the big questions of how to use AI tools, friction creeps into collaboration and the project suffers.

So this article tries to distill recommended practices for AI programming for software engineers, downplaying specific tools and tricks (Spec-driven or not?) and focusing on the more universal questions (should a junior engineer fully delegate bug fixes to an AI agent?).

The content is split into two parts: "For Everyone" and "For Junior Engineers." The junior-engineer section is tailored to the particular stage those engineers are at.

Note: parts of this article were co-created with jianan and wklken. The views here are distilled from the author's own working environment and may not fully apply to other projects — take what fits.

Remember: the agent doesn't own the code.

An AI agent extends a person's capabilities — it's a kind of "stand-in" — but it bears no direct responsibility. The human remains the final owner of the code.

Review the code AI generates and understand it. Never commit code you don't understand. How do you know you really understand something? The Feynman technique: can you explain it to someone with no background in it?

Don't lean on others (or AI) to do the final gatekeeping on your work at review time — that's a dereliction of your own responsibility.

Two mental models: "collaboration" means making decisions together with the other party on the basis of understanding; "delegation" means caring only about the end result.

To repeat: AI doesn't answer for the code, and it isn't accountable for the project's long-term maintainability either.

Don't play the product manager — handing down requirements in plain language from on high, with no interest in how they're implemented. "I don't care how you build it, this requirement is simple!"

Dig into the program design and overall structure, and work the answer out together with the agent.

AI writes code fast and in bulk, so it's easy to end up with PRs of thousands of changed lines.

A big PR makes review far harder; the review slides along the surface and quality control slips away.

Don't save up one giant "ultimate move" — keep PRs small (under 600 lines is a good target), move in small steps, and deliver in stages.

If a PR really can't be split, provide a design document for it (a design_notes directory) to help reviewers follow along.

Note: a design document is not a spec spelled out down to the code level. It's a human-readable "manual" written at a higher level of abstraction. Write the core content or skeleton yourself; AI can help fill in details.

Make good use of plan mode, and explore up front.

For a new requirement, first get familiar with the relevant modules and domain knowledge and understand how the project currently implements things (AI can help you investigate and map it out).

Don't let AI start writing code before you genuinely understand the requirement; to repeat, use the Feynman technique to check whether you really do.

Ask questions first, or turn on plan mode to clarify the requirement with AI (and pick up some prompting skills along the way).

Don't let AI lead you by the nose — think independently, stay skeptical, and open up your thinking by questioning back. Only with a clear grasp of the problem can you judge whether AI's implementation is sound, and good judgment is priceless.

For utility functions and libraries, AI tends toward rolling its own rather than pulling in a third-party package. That's not to say reinventing the wheel is always wrong, but…

For well-solved problems in common domains (gjson, say), lean toward having AI adopt a library instead of implementing it from scratch. How do you know which libraries are a good fit? Talk to AI, or go dig through the docs yourself — everyday accumulation matters. When several libraries will do, let a human pick the best fit for the project (feature match, activity level, future evolution, and so on).

Before opening a new PR, use an AI agent to review your current changes and adjust the code based on its suggestions. An up-front AI review lightens the later human review and speeds up the iteration loop. Any review SKILL or a simple prompt will do. Here's an example prompt:

You are a code review expert. Compare against the master branch to see all the changes in this project, review them, and produce a report. I care most about:

- Logic errors or unhandled edge cases;
- Common designs or constructs that go against language best practices;
- Overly complex classes/interfaces/functions that could be simplified;
- Patterns that may be security risks (SQL injection, for instance);
- Reimplementations of functionality that a mature library or another module already provides (failure to reuse);
- Anything else that breaks project conventions, consistency, or quality.

Note: reviewing before you open the PR doesn't replace the AI and human review that comes after — it's just an up-front self-check.

For code AI implements, do the work of automated testing and self-testing. Never commit untested code and leave it to review to catch what falls through — review can't find everything, and some problems only surface when the code actually runs. The later a bug is found, the more it costs to fix. Write automated tests (unit tests, API tests, and so on) so an AI agent can verify changes on its own and stay in a verify-fix loop.

Stay curious: when AI's code brings up a library, pattern, or snippet you find novel, chase it down to the bottom.

Push your limits: shake off mental inertia and take on tasks you'd never have attempted "without an agent."

Do the right thing: if the requirement itself was wrong from the start, AI will race you down the wrong road at full speed — which is why "doing the right thing" has never mattered more.

Junior engineers without much experience are still early in their understanding of the language and the project domain. Leaning too heavily on AI at this stage can undercut learning and, over the long run, hurt their growth. So here's advice aimed specifically at them:

AI is an efficiency tool, but early in your career you should care more about quality than speed.

Shipping low-quality code fast is actually less efficient — it means review rounds that keep coming back, plus technical debt.

If a slower path teaches you more, take the slower path (once you've agreed on the deadline).

AI agents are very good at fully automatic bug fixing, but for a junior engineer… don't just toss the whole thing at the agent and let it run unattended.

Work in chat mode: offer your own thinking and questions, and deepen your understanding of the project as you analyze the bug. That helps you grasp the code logic and architecture faster and more deeply.

To repeat: treat the agent as a collaborator to work alongside, not something to hand everything off to.

For any task, AI gives you the "most likely to hold up" answer, but it may not suit you. Following it blindly costs you the chance to broaden your own technical horizons.

Spend a fixed amount of time first (half an hour, say) designing your own approach, then ask AI and compare its thinking against yours — come up with your own answer before you check the key.

Push the agent to its limits to find out what it can really do.

Have AI question you back, using Q&A to deepen your grasp of the project and the related technology — like having AI run a mock "interview" about the project.

Read the official docs: AI knowledge has a cutoff date and hallucinates, so documentation is still the first choice for really mastering a technology (slow is fast).

Fill in your gaps in software design and architecture patterns — learn design patterns, domain-driven design (DDD), and the like. At this stage AI isn't good at overall design; it's better at concrete, function-level implementation within a clear framework.

Good design and robust, flexible architecture are what keep a project iterating sustainably, and that needs a human at the helm. Build your own body of knowledge by reading books.

Watch the non-functional requirements: AI tends to default to "make the feature run" and overlooks the rest of engineering — security, maintainability, concurrency safety, scalability. Pay attention to them deliberately.

If you have a different view or something to add, the discussion is open.