Agentic Development
Agent式开发
This skill provides guidance for building software with AI agents based on real-world experience from high-volume agentic development, specifically Peter Steinberger's "Just Talk To It" methodology developed while building a ~300k LOC TypeScript React application entirely with AI agents.
Core Philosophy: Most elaborate frameworks, planning systems, and tooling are premature optimization. Treat AI agents like capable engineers—talk naturally, develop shared context, interrupt when needed, and iterate based on results rather than elaborate plans.
本技能基于大规模Agent开发的实战经验，为使用AI Agent构建软件提供指导，具体参考了Peter Steinberger在完全借助AI Agent开发一个约30万行TypeScript React应用时所总结的"Just Talk To It"方法论。
核心理念：大多数复杂的框架、规划系统和工具都属于过早优化。将AI Agent视为能力出众的工程师——用自然的方式沟通，建立共享上下文，必要时打断，并基于结果而非详尽计划进行迭代。
When to Use This Skill
何时使用本技能
Apply this skill when users ask about:
- Setting up agentic development workflows
- Choosing tools and models for AI-assisted coding
- Optimizing prompt strategies and context management
- Parallel agent workflows and git management
- Debugging agent behavior or improving output quality
- Evaluating whether to use MCPs, subagents, or other abstractions
- Refactoring strategies with agents
- Testing approaches with AI assistance
当用户询问以下内容时，可应用本技能：
- 搭建Agent式开发工作流
- 选择AI辅助编码的工具和模型
- 优化提示词策略与上下文管理
- 并行Agent工作流与Git管理
- 调试Agent行为或提升输出质量
- 评估是否使用MCP、子Agent或其他抽象层
- 借助Agent进行重构的策略
- AI辅助的测试方法
1. Think in Blast Radius, Not Complexity
1. 关注影响范围，而非复杂度
Plan changes by file impact rather than perceived difficulty.
Application:
- Before starting, estimate: "Will this touch 3 files or 30?"
- Recognize that multiple large-radius changes prevent isolated commits and complicate recovery
- When an agent takes longer than anticipated, interrupt (escape key) and ask "what's the status?"
- Use "give me a few options before making changes" when uncertain about impact
- Trust that file changes are atomic—agents resume well after interruption
Guidance Pattern: When a user describes a task, help gauge blast radius by asking: "How many files do you think this will touch?" This builds intuition for redirecting agents.
根据文件影响范围规划变更，而非感知到的难度。
应用方式：
- 开始前预估："这项变更会涉及3个文件还是30个？"
- 要意识到，多个大范围变更会阻碍独立提交，使回滚复杂化
- 当Agent耗时超出预期时，打断（按ESC键）并询问"当前进度如何？"
- 不确定影响范围时，使用"在做变更前先给我几个选项"
- 相信文件变更具备原子性——Agent被打断后可顺利恢复工作
指导模式：当用户描述任务时，通过询问"你认为这项变更会涉及多少个文件？"来帮助评估影响范围，以此培养引导Agent的直觉。
2. Model Selection and Economics
2. 模型选择与成本考量
Subscription Economics: Running 4-5 AI subscriptions (~$1k/month) provides effectively unlimited tokens versus per-API-call pricing that costs 5-10x more. This enables context-wasteful usage and multiple parallel agents.
Model Characteristics:
- GPT-5-Codex: Reads extensively before acting, requires shorter prompts (1-2 sentences often suffice), more cautious with pushback on questionable requests, introverted communication style
- Claude Sonnet: More eager to start, requires more explicit direction, verbose communication ("absolutely right", "100% production ready")
Guidance Pattern: When advising on model choice, emphasize that model personality affects mental health and productivity. The difference between aggressive optimism (while tests fail) versus quiet progress-making materially impacts burnout.
订阅经济：同时使用4-5个AI订阅服务（约1000美元/月）可获得近乎无限的token，相比按API调用计费的方式成本低5-10倍。这允许我们不必刻意节省上下文，还能同时运行多个并行Agent。
模型特性：
- GPT-5-Codex：行动前会进行大量阅读，所需提示词更短（通常1-2句话即可），对有问题的请求会更谨慎地反驳，沟通风格偏内向
- Claude Sonnet：更急于开始工作，需要更明确的指令，沟通风格偏 verbose（常用"完全正确"、"100%可用于生产环境"等表述）
指导模式：在建议模型选择时，要强调模型的"个性"会影响开发者的心理健康和工作效率。在测试失败时，是激进的乐观态度还是沉稳的推进方式，对避免职业倦怠有着实质性影响。
3. Parallel Agents in One Folder
3. 单文件夹内运行并行Agent
Run 3-8 agents simultaneously in the same directory with one dev server, rather than git worktrees or branch-per-feature.
Advantages:
- Test multiple changes at once in running application
- Faster than spawning multiple dev servers or switching branches
- Agents perform atomic commits themselves
- Trade some isolation for velocity gains
Requirements:
- Agents must commit only their own changes (requires clear instruction file)
- Single shared dev server for testing
- Accept some git history messiness (clean in batches later)
Guidance Pattern: When users struggle with worktrees or branch management, suggest trying parallel agents in one folder for a week. Initial skepticism often gives way to appreciation.
在同一目录下同时运行3-8个Agent，并使用同一个开发服务器，而非使用Git工作区或按功能分分支。
优势：
- 可在运行中的应用里同时测试多项变更
- 比启动多个开发服务器或切换分支更快
- Agent会自行完成原子提交
- 以牺牲部分隔离性为代价换取速度提升
要求：
- Agent必须只提交自己的变更（需要清晰的指令文件）
- 使用单个共享开发服务器进行测试
- 接受Git历史的混乱（后续可批量清理）
指导模式：当用户在Git工作区或分支管理上遇到困难时，建议尝试在单文件夹内运行并行Agent一周。最初的怀疑往往会转变为认可。
4. Screenshots Are 50% of Context Engineering
4. 截图是上下文工程的50%
Drag screenshots into terminal (showing UI, code, or errors) rather than writing lengthy text descriptions.
Effectiveness:
- Models excel at visual context
- Find exact strings, match patterns, jump to correct locations
- Takes 2 seconds versus minutes of detailed typing
- More token-efficient than text explanations
Guidance Pattern: If a user writes long descriptions of what they see, interrupt and suggest: "Just screenshot it and drag into the terminal."
将截图拖入终端（展示UI、代码或错误），而非编写冗长的文字描述。
效果：
- 模型擅长处理视觉上下文
- 可快速定位精确字符串、匹配模式、跳转至正确位置
- 仅需2秒，相比手动输入详细描述节省数分钟时间
- 相比文字解释，token使用效率更高
指导模式：如果用户长篇大论地描述所见内容，打断并建议："直接截图拖入终端即可。"
5. Better Models Need Shorter Prompts
5. 更优秀的模型需要更短的提示词
More capable models require less prompt verbosity because they compensate through better reconnaissance.
GPT-5-Codex Pattern:
- 1-2 sentences often suffice
- Reads extensively before acting
- Strong world knowledge reduces explanation needs
Claude Pattern:
- Benefits from more extensive context
- Better comprehension with additional detail
- Requires more explicit direction
Guidance Pattern: If a user writes elaborate prompts for GPT-5, suggest trying shorter versions. The model's file-reading behavior often makes detailed specs unnecessary.
能力越强的模型所需的提示词越简洁，因为它们能通过更出色的"侦察"能力进行弥补。
GPT-5-Codex模式：
- 通常1-2句话足够
- 行动前会进行大量阅读
- 丰富的通用知识减少了额外解释的需求
Claude模式：
- 从更丰富的上下文中获益
- 额外的细节有助于提升理解
- 需要更明确的指令
指导模式：如果用户为GPT-5-Codex编写冗长的提示词，建议尝试更简短的版本。模型的文件读取行为通常会让详细的规格说明变得多余。
6. Context Tax Is Real—CLIs Beat MCPs
6. 上下文成本真实存在——CLI优于MCP
MCPs consume context tokens on every interaction, creating permanent overhead.
CLI Advantages:
- Shows help menu on first incorrect invocation
- Model learns forever without recurring cost
- Example: GitHub MCP costs ~23k tokens; CLI costs zero
- Models possess strong world knowledge of popular CLIs
Exception: Chrome DevTools MCP for closing debugging loops justifies context cost in specific scenarios.
Guidance Pattern: When users discuss building an MCP, challenge: "Could this be a CLI instead?" Most tools should be CLIs unless deep integration justifies the context tax.
MCP在每次交互时都会消耗上下文token，产生永久性的开销。
CLI优势：
- 首次调用错误时会显示帮助菜单
- 模型可永久学习，无重复成本
- 示例：GitHub MCP约消耗23000个token；而 CLI消耗为0
- 模型对主流CLI工具具备丰富的通用知识
例外情况：Chrome DevTools MCP在特定场景下可缩短调试周期，其上下文成本是合理的。
指导模式：当用户讨论构建MCP时，提出质疑："能不能用CLI替代？"除非深度集成的需求能证明上下文成本的合理性，否则大多数工具都应该采用CLI形式。
7. Interrupting Agents Is Standard Practice
7. 打断Agent是标准操作
Break the assumption inherited from traditional programming that tasks must run to completion.
Practice:
- Hit escape mid-task and ask "what's the status?"
- Models resume where they stopped
- File changes are atomic
- Enables active steering and course correction
Guidance Pattern: When users hesitate about interrupting, reassure: "Think of it like checking in with a junior engineer. They'll pick up where they left off."
打破传统编程中任务必须运行至完成的固有认知。
实践方法：
- 任务执行中途按ESC键并询问"当前进度如何？"
- 模型会从中断处恢复工作
- 文件变更具备原子性
- 支持主动引导和路线修正
指导模式：当用户对打断Agent有所顾虑时，打消其疑虑："就像和初级工程师沟通时的中途检查一样，他们会从停下的地方继续。"
8. Refactoring Is Low-Focus Work
8. 重构是低专注度工作
Spend ~20% of time on agent-driven refactoring when tired or needing less focus.
Paradigm Shift: Traditional views require peak concentration for refactoring. With agents, it becomes mechanical work requiring only strategic oversight.
Refactoring Tasks:
- Code deduplication (jscpd)
- Dead code removal (knip)
- ESLint plugins (react-compiler, deprecation)
- Adding tests and comments for tricky parts
- Dependency updates and tool upgrades
- File restructuring
- Rewriting slow tests
- Modernizing patterns (e.g., removing unnecessary )
Guidance Pattern: When users feel burned out on feature work, suggest: "Try a refactoring day. Queue cleanup tasks and let agents handle mechanical work while maintaining high-level oversight."
在感到疲惫或需要低专注度工作时，将约20%的时间用于Agent驱动的重构。
范式转变：传统观念认为重构需要高度专注。但借助Agent，重构变成了只需战略监督的机械性工作。
重构任务：
- 代码去重（使用jscpd）
- 移除死代码（使用knip）
- ESLint插件（如react-compiler、deprecation）
- 为复杂代码添加测试和注释
- 依赖更新与工具升级
- 文件结构调整
- 重写缓慢的测试
- 现代化代码模式（如移除不必要的）
指导模式：当用户在功能开发中感到倦怠时，建议："试试安排一天进行重构。列出清理任务，让Agent处理机械性工作，你只需保持高层级的监督。"
9. Same-Context Testing Catches Fresh Bugs
9. 同上下文测试可发现新引入的Bug
After implementing features, request tests in the same context.
Effectiveness:
- Agent has full context of what it just built
- Often discovers bugs in its own implementation
- Far more effective than separate test-writing sessions
- Tests reflect actual implementation details
Exception: Purely UI tweaks may not warrant immediate testing.
Guidance Pattern: Establish this habit: "After each feature or fix, ask the model to write tests. Use the same context." While AI generally writes mediocre tests, this approach helps catch its own bugs.
完成功能实现后，在同一上下文下请求编写测试。
效果：
- Agent对刚构建的内容具备完整上下文
- 通常能发现自身实现中的Bug
- 比单独的测试编写环节有效得多
- 测试能准确反映实际实现细节
例外情况：纯UI调整可能不需要立即编写测试。
指导模式：养成习惯："完成每个功能或修复后，让模型在同一上下文下编写测试。"虽然AI编写的测试质量通常一般，但这种方法有助于发现它自身引入的Bug。
10. Plan Mode Is Workaround Theater
10. 规划模式是无用的形式主义
Elaborate planning frameworks, spec-driven development, and multi-agent orchestration often work around model weaknesses rather than embracing strengths.
Better Approach with Strong Models:
- Use "let's discuss" or "give me options"
- Model will wait for approval
- No harness ceremony needed
Spec-Driven Alternative: For complex features, discuss with the agent, iterate on ideas, optionally request a spec, get review from another model (GPT-5-Pro), then paste useful parts back.
UI Work Approach: Deliberately under-spec UI requests, watch the model build in real-time, iterate by morphing chaos into the right shape. Often discovers interesting solutions not initially envisioned.
Guidance Pattern: When users describe elaborate planning systems, ask: "What if you just talked to the model about what you want?" If elaborate ceremony is needed, the model probably isn't good enough yet.
复杂的规划框架、基于规格的开发和多Agent编排往往是在弥补模型的不足，而非利用其优势。
针对强模型的更佳方法：
- 使用"我们来讨论一下"或"给我几个选项"
- 模型会等待你的批准
- 无需复杂的框架仪式
基于规格的替代方案：对于复杂功能，先与Agent讨论，迭代想法，可选择性地请求生成规格，再让另一个模型（如GPT-5-Pro）审核，最后将有用的部分粘贴回来。
UI工作方法：故意模糊UI需求的细节，实时观察模型的构建过程，通过迭代将混乱逐步塑造成理想的形态。这往往能发现最初未设想的有趣解决方案。
指导模式：当用户描述复杂的规划系统时，询问："如果你直接和模型沟通需求会怎样？"如果需要复杂的仪式，说明当前使用的模型还不够优秀。
11. Agent Files Are Organizational Scar Tissue
11. Agent文件是组织的疤痕组织
Instruction files (~800 lines) should evolve organically as problems arise, not be architected upfront.
Maintenance:
- Request agent updates when things go wrong
- Treat as living document of codebase quirks and preferences
- Clean periodically as models improve
- Expect content reduction as models gain better world knowledge
Content Examples:
- Git instructions for multi-agent workflows
- Product explanation and naming patterns
- Preferred React patterns
- Database migration management
- Testing conventions
- AST-grep rules
- Text-based design system guidelines
Prompt Style Differences:
- Claude responds to ALL-CAPS warnings and emphatic language
- GPT-5 prefers natural human language
- Files optimized for one model may not transfer well
Guidance Pattern: Don't help users write instruction files from scratch. Instead: "Start with basics, then ask your agent to add notes every time something goes wrong. It'll grow organically into exactly what you need."
指令文件（约800行）应随着问题的出现自然演化，而非预先架构。
维护方式：
- 出现问题时，请求Agent更新指令文件
- 将其视为代码库特性和偏好的动态文档
- 随着模型能力提升定期清理
- 随着模型通用知识的增长，文件内容会逐渐减少
内容示例：
- 多Agent工作流的Git指令
- 产品说明与命名模式
- 首选的React模式
- 数据库迁移管理
- 测试规范
- AST-grep规则
- 基于文本的设计系统指南
提示词风格差异：
- Claude对全大写警告和强调性语言响应更好
- GPT-5偏好自然的人类语言
- 为某一模型优化的文件可能无法直接适配其他模型
指导模式：不要帮助用户从头编写指令文件。相反，建议："从基础内容开始，每次出现问题时让Agent添加注释。它会自然演化成你恰好需要的样子。"
12. Queue Messages for Lazy Automation
12. 队列消息实现懒人自动化
Instead of crafting perfect prompts to motivate continued work, queue multiple "continue" messages when stepping away.
Mechanism:
- Model works through queued messages
- Ignores extras when done
- Crude but effective for long-running tasks
Platform Support: GPT-5-Codex supports message queuing; Claude Code changed to "steering" behavior instead.
Guidance Pattern: "For big refactors, queue a few 'continue' messages and step away. The model will either finish or reach a useful stopping point."
无需编写完美的提示词来激励模型持续工作，在离开前队列多条"继续"消息即可。
机制：
- 模型会依次处理队列中的消息
- 完成后会忽略多余的消息
- 方法粗糙但对长任务有效
平台支持：GPT-5-Codex支持消息队列；Claude Code已改为"引导"行为。
指导模式："对于大型重构任务，队列几条'继续'消息然后离开。模型要么完成任务，要么会停在一个有用的节点。"
13. Intuition Compounds Faster Than Frameworks
13. 直觉的积累速度快于框架
Direct interaction with agents builds intuition faster than elaborate frameworks.
Skills Developed:
- Blast radius estimation
- Stopping timing
- Under-specification appropriateness
- Test necessity judgment
- Effective steering
Transfer: Senior engineering skills (managing humans) apply to managing AI agents.
Guidance Pattern: Encourage direct usage over framework exploration: "The fastest path to competence is high-volume direct interaction. Tools will converge toward simplicity as models improve. What won't be commoditized is intuition."
与Agent的直接交互比复杂框架更能快速培养直觉。
培养的技能：
- 影响范围预估
- 中断时机判断
- 模糊需求的合理性判断
- 测试必要性判断
- 有效引导能力
迁移性：高级工程师的技能（管理人类）可应用于管理AI Agent。
指导模式：鼓励直接使用Agent而非探索框架："提升能力的最快路径是高频直接交互。随着模型的进步，工具会逐渐趋于简洁。而直觉是无法被商品化的。"
14. Subagents and Complexity Are Often Unnecessary
14. 子Agent和复杂性往往不必要
Historical Context:
- May 2024: "Subtasks" for parallelization and context reduction
- Later: Rebranded to "subagents" with instruction packaging
- Often used to work around model limitations
Alternative Approach: Use separate terminal panes/windows for different tasks, providing:
- Complete control over context engineering
- Visibility into what's sent
- Easier steering
- No hidden context management
Guidance Pattern: When users ask about subagents, suggest: "Try doing that work in a separate terminal window instead. More control and visibility."
历史背景：
- 2024年5月：为了并行化和减少上下文引入"子任务"
- 之后：重新包装为带指令的"子Agent"
- 通常用于弥补模型的局限性
替代方法：使用单独的终端窗格/窗口处理不同任务，这样：
- 可完全控制上下文工程
- 能清晰看到发送的内容
- 更易于引导
- 无隐藏的上下文管理
指导模式：当用户询问子Agent时，建议："试试在单独的终端窗口中处理这项工作。这样能获得更多控制和可见性。"
15. Background Tasks and Tooling Gaps
15. 后台任务与工具缺口
Current Limitation: Not all tools have perfect background task management.
Workaround Example: Use tmux for persistent CLI sessions in background:
- "run via tmux" often suffices
- Leverages existing world knowledge
- No custom agent instructions needed
Guidance Pattern: When users hit tool limitations, look for standard Unix/development tools that solve the problem. Models often have strong world knowledge of these.
当前局限性：并非所有工具都具备完善的后台任务管理能力。
变通方案示例：使用tmux在后台运行持久化CLI会话：
- 只需输入"run via tmux"
- 利用模型已有的通用知识
- 无需自定义Agent指令
指导模式：当用户遇到工具局限性时，寻找能解决问题的标准Unix/开发工具。模型通常对这些工具具备丰富的知识。
Prompting Strategies
提示词策略
For GPT-5-Codex
针对GPT-5-Codex
- Length: 1-2 sentences + screenshot often suffice
- Tone: Natural human language without emphasis
- Trigger words for difficult problems: "take your time", "comprehensive", "read all code that could be related", "create possible hypothesis"
- Avoid: ALL-CAPS, excessive emphasis, threatening language
- 长度：1-2句话+截图通常足够
- 语气：自然的人类语言，无需强调
- 解决难题的触发词："慢慢来"、"全面处理"、"阅读所有相关代码"、"提出可能的假设"
- 避免：全大写、过度强调、带有威胁性的语言
- Length: More extensive context beneficial
- Tone: Can leverage emphatic language and ALL-CAPS for critical instructions
- Style: More explicit direction helpful
- 长度：更丰富的上下文会更有帮助
- 语气：可使用强调性语言和全大写来标注关键指令
- 风格：更明确的指令会更有效
- Images: Use screenshots liberally—aim for 50% of prompts containing visual context
- Voice input: Whispr Flow with semantic correction recommended for efficiency
- Preservation: Request "preserve intent" and "add code comments on tricky parts"
- Intent clarity: Be explicit about what should and shouldn't change
- 图片：大量使用截图——目标是50%的提示词包含视觉上下文
- 语音输入：推荐使用带语义修正的Whispr Flow以提升效率
- 保留意图：请求模型"保留意图"并"为复杂代码添加注释"
- 意图明确：明确说明哪些内容需要修改，哪些不需要
When to Use Web Search
何时使用网页搜索
- Current events or rapidly changing information
- Verifying technical details beyond knowledge cutoff
- Finding documentation for new tools/libraries
- 当前事件或快速变化的信息
- 验证知识截止日期之后的技术细节
- 查找新工具/库的文档
GPT-5-Codex:
- Daily driver for most work
- Efficient context use (~230k usable)
- Fast, lightweight
- Shorter prompts needed
- More careful file reading before acting
Claude Code:
- When latest Sonnet capabilities needed
- If verbose communication preferred
- Good for tasks requiring high context (with caveats about context efficiency)
Local/Open Models:
- Keep monitoring but not recommended as daily driver yet
- China's models (GLM 4.6, Kimi K2.1) approaching Sonnet 3.7 quality
GPT-5-Codex：
- 大多数工作的日常首选
- 上下文使用效率高（约23万可用token）
- 快速、轻量化
- 所需提示词更短
- 行动前会更仔细地阅读文件
Claude Code：
- 需要最新Sonnet能力时使用
- 偏好verbose沟通风格时使用
- 适合需要高上下文的任务（需注意上下文效率）
本地/开源模型：
- 持续关注但暂不推荐作为日常首选
- 国内模型（GLM 4.6、Kimi K2.1）已接近Sonnet 3.7的质量
Slash Commands (Use Sparingly)
斜杠命令（谨慎使用）
Most interaction should be natural language, but a few commands can be useful:
- - When clarifying multi-agent folder commits
- - Occasionally useful, but review bots often superior
- Custom commands for specific workflows
Principle: Avoid ceremony when confident in requests. Develop intuition for when commands add value.
大多数交互应使用自然语言，但少数命令会很有用：
- - 当需要明确多Agent文件夹的提交规则时
- - 偶尔有用，但审核机器人通常更出色
- 针对特定工作流的自定义命令
原则：当对请求有信心时，避免形式主义。培养判断何时使用命令能增加价值的直觉。
Conversational Interaction Approach
对话式交互方法
1. Assess Current Context
1. 评估当前上下文
- Inquire about current workflow before suggesting changes
- Understand frustrations (speed, clarity, cost)
- Gauge experience level with agents
- 在建议变更前，先询问用户当前的工作流
- 了解用户的痛点（速度、清晰度、成本）
- 评估用户的Agent使用经验水平
2. Prioritize High-Impact Changes
2. 优先选择高影响的变更
- If using worktrees → suggest parallel agents in one folder
- If writing long prompts → suggest shorter ones with screenshots
- If using MCPs → challenge whether CLIs would work better
- If building elaborate frameworks → suggest direct agent interaction
- 如果用户使用Git工作区 → 建议在单文件夹内运行并行Agent
- 如果用户编写长提示词 → 建议结合截图使用更短的提示词
- 如果用户使用MCP → 质疑是否可改用CLI
- 如果用户构建复杂框架 → 建议直接与Agent交互
3. Foster Intuition Development
3. 培养直觉
- Share principles while emphasizing that intuition develops through practice
- Encourage experimentation with time-boxed trials
- Help develop sense of blast radius, interruption timing, and context management
- 在分享原则的同时，强调直觉需通过实践积累
- 鼓励进行限时实验
- 帮助用户培养影响范围预估、中断时机判断和上下文管理的能力
4. Common Frustration Responses
4. 常见痛点的应对
Git history concerns
→ Add commit instructions to agent file, or accept messiness and clean in batches
Instruction adherence issues
→ Could be model choice (GPT-5 follows better), or instructions need refinement
Cost concerns
→ Consider subscriptions vs API pricing; subscriptions are 5-10x cheaper for heavy use
Output quality issues
→ Schedule regular refactoring time (20% of work) as low-focus maintenance
Stopping uncertainty
→ Develops with intuition; start by interrupting frequently and checking status
Git历史混乱的顾虑
→ 在Agent指令文件中添加提交规则，或接受混乱并后续批量清理
指令不被遵守的问题
→ 可能是模型选择问题（GPT-5的依从性更好），或指令需要优化
成本顾虑
→ 对比订阅和API计费方式；对于高频使用场景，订阅成本低5-10倍
输出质量问题
→ 定期安排重构时间（占工作的20%）作为低专注度维护
不确定何时中断的问题
→ 直觉需逐步培养；从频繁中断并检查进度开始
5. Discourage Over-Engineering
5. 避免过度工程
- Most elaborate systems represent premature optimization
- Direct conversation often outperforms complex frameworks
- Tools converge to simplicity as models improve
- 大多数复杂系统都属于过早优化
- 直接对话往往优于复杂框架
- 随着模型进步，工具会逐渐趋于简洁
6. Emphasize Direct Experience
6. 强调直接经验
- High-volume direct interaction beats framework mastery
- Fastest learning comes from actual usage, not reading
- Senior engineering skills transfer: managing agents parallels managing humans
- 高频直接交互优于框架掌握
- 最快的学习方式是实际使用，而非阅读
- 高级工程师的技能可迁移：管理Agent与管理人类有共通之处
Anti-Patterns to Address
需要纠正的反模式
When users describe these approaches, gently suggest alternatives:
- Elaborate planning documents before starting → Suggest discussion-based approach
- Complex RAG systems for code → GPT-5 searches adequately
- Multiple layers of subagents → Suggest separate terminal windows
- Long instruction files from day one → Should evolve organically
- Excessive MCPs → Most should be CLIs
- Treating agents as non-interruptible → Emphasize atomicity
- Waiting for perfect prompts → Queue "continue" messages and iterate
- Writing all code manually still → Suggest letting agents handle more, including refactoring
- Using elaborate frameworks → Often unnecessary with good models
- Not using screenshots → Missing 50% of effective context engineering
当用户描述以下做法时，温和地建议替代方案：
- 开始前编写复杂的规划文档 → 建议采用基于讨论的方法
- 为代码构建复杂的RAG系统 → GPT-5的搜索能力已足够
- 多层子Agent架构 → 建议使用单独的终端窗口
- 从第一天就编写冗长的指令文件 → 应让其自然演化
- 过度使用MCP → 大多数应改用CLI
- 将Agent视为不可中断的任务 → 强调变更的原子性
- 等待完美的提示词 → 队列"继续"消息并逐步迭代
- 仍手动编写所有代码 → 建议让Agent处理更多工作，包括重构
- 使用复杂框架 → 在优秀模型的加持下往往不必要
- 不使用截图 → 错失了50%的有效上下文工程手段
Skill Development Progression
技能提升路径
As users gain experience, guide them through refinement stages:
Early Stage (Weeks 1-4)
初期（第1-4周）
- Focus on basic workflow: model choice, terminal setup, git management
- Practice interrupting agents and checking status
- Start small instruction file, allow organic growth
- Get comfortable with parallel agents (if applicable)
- 专注于基础工作流：模型选择、终端设置、Git管理
- 练习打断Agent并检查进度
- 从简单的指令文件开始，允许其自然增长
- 熟悉并行Agent的使用（如适用）
Intermediate (Months 2-3)
中期（第2-3个月）
- Develop blast radius intuition
- Optimize prompting for chosen model
- Establish refactoring rhythm
- Build personal slash commands (if needed)
- 培养影响范围预估的直觉
- 针对所选模型优化提示词
- 建立重构节奏
- 构建个人斜杠命令（如需要）
Advanced (Months 4+)
高级阶段（第4个月及以后）
- Fine-tune agent instruction file for codebase
- Develop strong intuition for stopping/redirecting timing
- Master context engineering with screenshots
- Experiment with under-specification for creative solutions
- Optimize subscription/API economics
- 针对代码库微调Agent指令文件
- 培养强大的中断/重定向时机判断直觉
- 掌握结合截图的上下文工程技巧
- 尝试模糊需求以获得创意解决方案
- 优化订阅/API的成本结构
Model-Specific Patterns
模型特定行为模式
GPT-5-Codex Behaviors
GPT-5-Codex行为
- Reads extensively before acting
- Sometimes panics mid-refactor and reverts (re-run with soothing language)
- Occasionally forgets bash commands are available
- Rarely replies in wrong language
- May lose lines when scrolling quickly
- Generally honors instruction file well
- 行动前会进行大量阅读
- 重构中途有时会恐慌并回滚（使用安抚性语言重新运行）
- 偶尔会忘记bash命令可用
- 极少用错误语言回复
- 快速滚动时可能会丢失代码行
- 通常能很好地遵守指令文件
Claude Sonnet Behaviors
Claude Sonnet行为
- More eager to start working
- Benefits from emphatic instruction style
- Creates random markdown files (older versions)
- May need stronger direction to follow instructions
- Better at context comprehension than file location
- 更急于开始工作
- 从强调性的指令风格中获益更多
- 旧版本会创建随机的Markdown文件
- 可能需要更强烈的指令才能遵守要求
- 上下文理解能力优于文件定位能力
Implementation Principles
实施原则
- Reduce Ceremony: Most "best practices" are premature optimization
- Just Talk To It: Natural interaction beats elaborate systems
- Develop Intuition: Compounds faster than framework mastery
- Embrace Simplicity: Tools will converge; intuition won't be commoditized
- Iterate on Results: What you see > what you planned
- Context Is King: Screenshots, short prompts, CLI tools over MCPs
- Mental Health Matters: Model personality affects productivity through burnout prevention
- Refactoring Is Maintenance: Regular cleanup at low-focus times keeps codebase healthy
- Tests Catch Agent Bugs: Write them in same context after implementation
- Trust the Process: File changes are atomic, interruption is fine, chaos can be shaped
- 减少形式主义：大多数"最佳实践"都是过早优化
- 直接沟通：自然交互优于复杂系统
- 培养直觉：直觉的积累速度快于框架掌握
- 拥抱简洁：工具会逐渐趋于简洁，而直觉无法被商品化
- 基于结果迭代：所见即所得优于计划
- 上下文为王：优先使用截图、短提示词、CLI工具而非MCP
- 心理健康重要：模型个性通过预防倦怠影响工作效率
- 重构是维护：定期在低专注度时间进行清理，保持代码库健康
- 测试发现Agent引入的Bug：在实现后同一上下文下编写测试
- 信任流程：文件变更具备原子性，打断是安全的，混乱可被塑造成有序