<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>Best Practices on On My Way</title>
    <link>https://tuanzi-wow.cn/tags/best-practices/</link>
    <description>Recent content in Best Practices on On My Way</description>
    <generator>Hugo</generator>
    <language>zh-CN</language>
    <lastBuildDate>Wed, 09 Sep 2026 19:00:52 +0800</lastBuildDate>
    <atom:link href="https://tuanzi-wow.cn/tags/best-practices/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Vibe Coding 最佳实践</title>
      <link>https://tuanzi-wow.cn/vibe-coding/vibe-coding-best-practices/</link>
      <pubDate>Wed, 09 Sep 2026 00:00:00 +0800</pubDate>
      <guid>https://tuanzi-wow.cn/vibe-coding/vibe-coding-best-practices/</guid>
      <description>Vibe coding 最佳实践：上下文与提示词、并行协作、验证优先与常见反模式。</description>
      <content:encoded><![CDATA[<h2 id="best-practices">Best practices</h2>
<h2 id="strong-first-use--context-and-prompts">Strong first use : Context and Prompts</h2>
<p>Clear prompting makes results more reliable
A good default is to include four things in your prompt:</p>
<ul>
<li><strong>Goal:</strong> What are you trying to change or build?</li>
<li><strong>Context:</strong> Which files, folders, docs, examples, or errors matter for this task? You can @ mention certain files as context.</li>
<li><strong>Constraints:</strong> What standards, architecture, safety requirements, or conventions should Codex follow?</li>
<li><strong>Done when:</strong> What should be true before the task is complete, such as tests passing, behavior changing, or a bug no longer reproducing?</li>
</ul>
<p>it is similar to Claude Code Best practices</p>
<h2 id="plan-first-for-difficult-tasks">Plan first for difficult tasks</h2>
<p>A few approaches work well:
<strong>Use Plan mode</strong>:/plan or Shift + Tab
<strong>Ask Codex to interview you</strong>: when your idea is ambiguous
<strong>Use a PLANS.md template</strong>: use PLANS.md</p>
<h2 id="make-guidance-reusable-with-agentsmd">Make guidance reusable with AGENTS.md</h2>
<p>Think of <code>AGENTS.md</code> as an open-format README for agents.</p>
<p>A good <code>AGENTS.md</code> covers:</p>
<ul>
<li>repo layout and important directories</li>
<li>How to run the project</li>
<li>Build, test, and lint commands</li>
<li>Engineering conventions and PR expectations</li>
<li>Constraints and do-not rules</li>
<li>What done means and how to verify work</li>
</ul>
<p>I think information above is very important!!!!
<strong>/init</strong> to scaffold a starter AGENTS.md
<strong>Keep it practical.</strong>
A short, accurate <code>AGENTS.md</code> is more useful than a long file full of vague rules.
If <code>AGENTS.md</code> starts getting too large, keep the main file concise and reference task-specific markdown files for things like planning, code review, or architecture.</p>
<h2 id="configure-codex-for-consistency">Configure Codex for consistency</h2>
<p>A good starting pattern is:</p>
<ul>
<li>Keep personal defaults in <code>~/.codex/config.toml</code> (<strong>Settings &gt; Configuration &gt; Open config.toml</strong> in the ChatGPT desktop app)</li>
<li>Keep repo-specific behavior in <code>.codex/config.toml</code></li>
<li>Use command-line overrides only for one-off situations (if you use the CLI)</li>
</ul>
<h2 id="improve-reliability-with-testing-and-review">Improve reliability with testing and review</h2>
<p>Don&rsquo;t stop at asking Codex to make a change. Ask it to create tests when needed, run the relevant checks, confirm the result, and review the work before you accept it.
Codex can do this loop for you, but only if it knows what “good” looks like. That guidance can come from either the prompt or <code>AGENTS.md</code>.
<strong>/review</strong> gives you a few ways to review code</p>
<p>If you and your team have a <code>code_review.md</code> file and reference it from <code>AGENTS.md</code>, Codex can follow that guidance during review as well.</p>
<h2 id="use-mcps-for-external-context">Use MCPs for external context</h2>
<p>Use MCP when:</p>
<ul>
<li>The needed context lives outside the repo</li>
<li>The data changes frequently</li>
<li>You want Codex to use a tool rather than rely on pasted instructions</li>
<li>You need a repeatable integration across users or projects</li>
</ul>
<p><code>codex mcp add</code> command in the CLI to add your custom servers with a name, URL, and other details.</p>
<h2 id="turn-repeatable-work-into-skills">Turn repeatable work into skills</h2>
<p>Use a <a href="https://learn.chatgpt.com/docs/build-skills">skill</a> to package the instructions in a <code>SKILL.md</code> file</p>
<p>What a skill.md file should include:
1.Keep each skill scoped to one job
2.Start with 2 to 3 concrete use cases
3.define clear inputs and outputs
4.write the description so it says what the skill does and when to use it
5.Include the kinds of trigger phrases a user would actually say</p>
<p>The often situation:</p>
<ul>
<li>Log triage</li>
<li>Release note drafting</li>
<li>PR review against a checklist</li>
<li>Migration planning</li>
<li>Telemetry or incident summaries</li>
<li>Standard debugging flows</li>
</ul>
<p>The <code>$skill-creator</code> skill is the best place to start to scaffold the first version of a skill.</p>
<h2 id="use-scheduled-tasks-for-repeated-work">Use scheduled tasks for repeated work</h2>
<p>Good candidates include:</p>
<ul>
<li>Summarizing recent commits</li>
<li>Scanning for likely bugs</li>
<li>Drafting release notes</li>
<li>Checking CI failures</li>
<li>Producing standup summaries</li>
<li>Running repeatable analysis workflows on a schedule</li>
</ul>
<h2 id="organize-long-running-chats">Organize long-running chats</h2>
<p>The ChatGPT desktop app lets you pin chats and create worktrees. If you use the CLI, these <a href="https://learn.chatgpt.com/docs/developer-commands?surface=cli">slash commands</a> are especially useful:</p>
<ul>
<li><code>/experimental</code> to toggle experimental features and add to your <code>config.toml</code></li>
<li><code>/resume</code> to resume a saved chat</li>
<li><code>/fork</code> to create a new chat while preserving the original transcript</li>
<li><code>/compact</code> when the chat is getting long and you want a summarized version of earlier context. Codex also compacts chats automatically</li>
<li><code>/agent</code> when you are running parallel agents and want to switch between the active agent thread</li>
<li><code>/theme</code> to choose a syntax highlighting theme</li>
<li><code>/apps</code> to use ChatGPT apps directly in Codex</li>
<li><code>/status</code> to inspect the current session state</li>
</ul>
<h2 id="common-mistakes">Common mistakes</h2>
<p>A few common mistakes to avoid when first using Codex:</p>
<ul>
<li>Overloading the prompt with durable rules instead of moving them into <code>AGENTS.md</code> or a skill</li>
<li>Not letting the agent see its work by not giving details on how to best run build and test commands</li>
<li>Skipping planning on multi-step and complex tasks</li>
<li>Giving Codex full permission to your computer before you understand the workflow</li>
<li>Running live tasks on the same files without using Git worktrees</li>
<li>Scheduling a recurring task before it&rsquo;s reliable manually</li>
<li>Treating Codex like something you have to watch step by step instead of using it in parallel with your own work</li>
<li>Using one chat for an entire project instead of one chat per coherent outcome. This leads to bloated context and worse results over time</li>
</ul>
]]></content:encoded>
    </item>
  </channel>
</rss>
