rain/shencaisuan
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

修改问题

Browse Source
This commit is contained in:
rain
2026-06-22 17:31:43 +08:00
parent b3e6f3e831
commit 830b1cf2e1
1 changed files with 20 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files
AGENTS.md
+20 -12
View File
@@ -4,7 +4,7 @@ Behavioral guidelines to reduce common LLM coding mistakes. Merge with project-s
Tradeoff: These guidelines bias toward caution over speed. For trivial tasks, use judgment. Tradeoff: These guidelines bias toward caution over speed. For trivial tasks, use judgment.
1. Think Before Coding 1. Think Before Coding
Don’t assume. Don’t hide confusion. Surface tradeoffs. Don't assume. Don't hide confusion. Surface tradeoffs.
Before implementing: Before implementing:
@@ -12,30 +12,32 @@ State your assumptions explicitly. If uncertain, ask.
If multiple interpretations exist, present them instead of picking silently. If multiple interpretations exist, present them instead of picking silently.
If a simpler approach exists, say so. Push back when warranted. If a simpler approach exists, say so. Push back when warranted.
If something is unclear, stop. Name what is confusing. Ask. If something is unclear, stop. Name what is confusing. Ask.
2. Simplicity First 2. Simplicity First
Minimum code that solves the problem. Nothing speculative. Minimum code that solves the problem. Nothing speculative.
No features beyond what was asked. No features beyond what was asked.
No abstractions for single-use code. No abstractions for single-use code.
No “flexibility” or “configurability” that was not requested. No "flexibility" or "configurability" that was not requested.
No error handling for impossible scenarios. No error handling for impossible scenarios.
If you write 200 lines and it could be 50, rewrite it. If you write 200 lines and it could be 50, rewrite it.
Ask yourself: “Would a senior engineer say this is overcomplicated?” If yes, simplify. Ask yourself: "Would a senior engineer say this is overcomplicated?" If yes, simplify.
3. Surgical Changes 3. Surgical Changes
Touch only what you must. Clean up only your own mess. Touch only what you must. Clean up only your own mess.
When editing existing code: When editing existing code:
Do not “improve” adjacent code, comments, or formatting. Do not "improve" adjacent code, comments, or formatting.
Do not refactor things that are not broken. Do not refactor things that are not broken.
Match existing style, even if you would do it differently. Match existing style, even if you would do it differently.
If you notice unrelated dead code, mention it instead of deleting it. If you notice unrelated dead code, mention it instead of deleting it.
When your changes create orphans: When your changes create orphans:
Remove imports, variables, functions, files, docs, and references that YOUR changes made unused. Remove imports, variables, functions, files, docs, and references that YOUR changes made unused.
Do not remove pre-existing dead code unless asked. Do not remove pre-existing dead code unless asked.
The test: Every changed line should trace directly to the user’s request. The test: Every changed line should trace directly to the user's request.
4. Contract Discipline 4. Contract Discipline
When a new contract lands, make it the only contract in the same change. When a new contract lands, make it the only contract in the same change.
@@ -49,11 +51,13 @@ Specify the single owner.
Identify the one module, function, schema, document, or service that owns the contract. Identify the one module, function, schema, document, or service that owns the contract.
Do not leave the same rule duplicated across frontend, backend, scripts, prompts, docs, or tests. Do not leave the same rule duplicated across frontend, backend, scripts, prompts, docs, or tests.
If multiple places need the value, they should consume it from the owner rather than redefine it. If multiple places need the value, they should consume it from the owner rather than redefine it.
Delete old fields and old entrypoints. Delete old fields and old entrypoints.
Remove obsolete fields, fallback reads, compatibility branches, legacy routes, stale config keys, old scripts, and old docs. Remove obsolete fields, fallback reads, compatibility branches, legacy routes, stale config keys, old scripts, and old docs.
Do not keep the old path “just in case” unless the user explicitly asks for a compatibility period. Do not keep the old path "just in case" unless the user explicitly asks for a compatibility period.
If compatibility is required, name it as temporary, define the removal condition, and keep it narrow. If compatibility is required, name it as temporary, define the removal condition, and keep it narrow.
Tighten validators and runtime together. Tighten validators and runtime together.
Update schemas, validators, tests, fixtures, seed data, docs, and runtime code in the same change. Update schemas, validators, tests, fixtures, seed data, docs, and runtime code in the same change.
@@ -66,16 +70,18 @@ Define success criteria. Loop until verified.
Transform tasks into verifiable goals: Transform tasks into verifiable goals:
“Add validation” → “Write tests for invalid inputs, then make them pass.” "Add validation" -> "Write tests for invalid inputs, then make them pass."
“Fix the bug” → “Write a test that reproduces it, then make it pass.” "Fix the bug" -> "Write a test that reproduces it, then make it pass."
“Refactor X” → “Ensure tests pass before and after.” "Refactor X" -> "Ensure tests pass before and after."
“Change a contract” → “Identify owner, remove old paths, tighten validators and runtime, then verify old inputs fail.” "Change a contract" -> "Identify owner, remove old paths, tighten validators and runtime, then verify old inputs fail."
For multi-step tasks, state a brief plan: For multi-step tasks, state a brief plan:
1. [Step] -> verify: [check] 1. [Step] -> verify: [check]
2. [Step] -> verify: [check] 2. [Step] -> verify: [check]
3. [Step] -> verify: [check] 3. [Step] -> verify: [check]
Strong success criteria let you loop independently. Weak criteria like “make it work” require clarification.
Strong success criteria let you loop independently. Weak criteria like "make it work" require clarification.
6. Verification Before Closure 6. Verification Before Closure
A change is not finished until the relevant behavior is checked. A change is not finished until the relevant behavior is checked.
@@ -99,9 +105,11 @@ Say how it was verified.
Mention any remaining risk or skipped verification. Mention any remaining risk or skipped verification.
Do not bury important caveats in vague language. Do not bury important caveats in vague language.
Do not over-explain routine edits. Do not over-explain routine edits.
Good final answer shape: Good final answer shape:
Changed: [short summary] Changed: [short summary]
Verified: [command/check] Verified: [command/check]
Notes: [only if needed] Notes: [only if needed]
These guidelines are working if: fewer unnecessary changes in diffs, fewer rewrites due to overcomplication, fewer hidden compatibility paths, clearer ownership of contracts, and clarifying questions happen before implementation rather than after mistakes.
These guidelines are working if: fewer unnecessary changes in diffs, fewer rewrites due to overcomplication, fewer hidden compatibility paths, clearer ownership of contracts, and clarifying questions happen before implementation rather than after mistakes.