Prática Geral: Adicionando Funcionalidade a uma Pequena Ferramenta TODO do Zero e Realizando um Commit
📚 Navegação da Série: O artigo anterior 〔33 Pontos Chave para Uso no Windows 〕 organizou um a um os problemas comuns no Windows — caminhos, quebras de linha, terminal e diferenças de sandbox. Neste artigo, não falaremos de novas funcionalidades, mas faremos algo muito mais empolgante: montar com as próprias mãos as peças aprendidas nos mais de trinta artigos anteriores em uma máquina funcional. O próximo artigo 〔35 Guia Rápido de Comandos e Configurações 〕 reunirá em uma única tabela todos os comandos e chaves de configuração usados em toda a série, para servir como um livro de consulta rápida a qualquer momento.
Pessoal, hoje não teremos aula teórica, vamos construir juntos algo pequeno do zero.
Tenho em mãos uma pequena ferramenta de linha de comando bastante simples — um todo.py escrito em Python, que consegue adicionar tarefas e listar tarefas, apenas essas duas funções. Ela tem uma limitação óbvia: uma vez adicionadas as tarefas, elas não podem ser deletadas após concluídas, restando apenas assistir a lista acumular cada vez mais. Neste artigo, passaremos pelo processo completo de adicionar a funcionalidade de "excluir tarefa": desde explicar o contexto, delegar a tarefa, configurar permissões, até a autoverificação e o commit com git.
Para ser franco, cada um dos artigos anteriores ensinou "como usar uma peça específica" — como escrever o AGENTS.md, como estruturar os prompts, como configurar permissões e como delegar o git a ele. Olhando individualmente tudo faz sentido, mas na hora de trabalhar de verdade, muitas pessoas ficam perdidas sobre em qual ordem essas peças devem ser usadas e como elas se encaixam. Este artigo é exatamente esse "mapa de montagem".
Não vou presumir que você já tenha esse projeto no seu computador. Na Seção 01, vou te guiar para criar este todo.py em dois minutos, e depois você poderá me acompanhar passo a passo, vendo os resultados com seus próprios olhos. Este é um artigo de "aprender fazendo", não apenas para "entender" — ler sem praticar é o mesmo que não ler.
Ao final deste artigo, você terá:
- Um fluxo de desenvolvimento completo do zero ao commit, com cada passo correspondendo a um artigo anterior, para criar memória muscular
- Um
AGENTS.mdpronto para copiar, um prompt de delegação de tarefas estruturado, além de comandos reais e suas saídas esperadas - A prática real de "deixar o Codex executar os testes para se autoverificar e não encerrar o trabalho até que tudo passe"
- Como um commit do
gitlimpo é entregue ao Codex, mantendo você no controle da aprovação final - Uma tabela comparativa de fluxo completo mostrando "qual habilidade de qual artigo está sendo usada nesta etapa", que você poderá aplicar em qualquer projeto futuro
⚠️ Qualquer comando, parâmetro ou comportamento padrão mencionado abaixo segue a documentação oficial do Codex; nomes de modelos e textos de interface podem mudar com as versions, portanto, guie-se pelo
codex --helplocal e pelo que for exibido na tela no momento, sem definições estritas neste texto.
01 Primeiro, Defina o "Alvo": Crie uma Ferramenta TODO em Dois Minutos
Antes de começar a trabalhar, precisamos de algo para modificar. Vamos criar este projeto manualmente primeiro — todas as operações subsequentes girarão em torno dele.
Analogia: Isso é como precisar de uma casa inacabada antes de começar a reforma. Sem a casa, mesmo o melhor projeto arquitetônico não sairá do papel. Este todo.py é a nossa casa inacabada, simples o suficiente para ser lido em um piscar de olhos, mas com "todas as paredes necessárias no lugar" — possui dados, funcionalidades e ponto de entrada, ideal para adicionarmos uma nova parede (a funcionalidade de exclusão).
Escolha um diretório vazio e crie um arquivo todo.py com o seguinte conteúdo (funciona no Mac, Linux e Windows, requer apenas Python 3):
# todo.py
import sys
TODOS = []
def add(item):
TODOS.append(item)
print(f"已添加：{item}")
def list_todos():
if not TODOS:
print("（暂无待办）")
return
for i, item in enumerate(TODOS, 1):
print(f"{i}. {item}")
def main():
if len(sys.argv) < 2:
print("用法：python todo.py [add <内容> | list]")
return
cmd = sys.argv[1]
if cmd == "add":
add(" ".join(sys.argv[2:]))
elif cmd == "list":
list_todos()
else:
print(f"未知命令：{cmd}")
if __name__ == "__main__":
main()Depois de criar o arquivo, execute-o para confirmar que está funcionando:
python todo.py add 买咖啡豆
python todo.py listSaída esperada:
已添加：买咖啡豆
（暂无待办）Observe que há uma "característica" aqui — como cada execução ocorre em um novo processo, a lista na memória TODOS é limpa após a execução, por isso a saída de list aparece vazia. Isso não é um bug, é a definição do nosso alvo mínimo. Lembre-se disso, pois usaremos essa informação na Seção 05 para validação.
Por fim, coloque-o sob o controle do Git (faremos um commit mais tarde):
git init
git add todo.py
git commit -m "init: TODO 小工具初版"Espera-se ver o Git reportando a criação de um commit. Com o alvo definido, vamos começar oficialmente.
💡 Resumo em uma frase: Primeiro, crie manualmente o alvo mínimo executável
todo.pyem dois minutos e coloque-o no Git para que cada passo subsequente tenha um objetivo claro.
02 Passo 1: Escrever o AGENTS.md para Explicar o Contexto do Projeto de Uma Só Vez
O Codex começa em um projeto como uma folha em branco — ele não sabe qual é o projeto, como executá-lo ou quais são as regras. A primeira coisa a fazer antes de começar é dar a ele uma "lista de entrega". Isso é exatamente o que foi abordado em 〔11 Manual do Projeto AGENTS.md 〕.
Analogia: Isso é como colar um "aviso do local" para um trabalhador temporário. Por melhor que seja o profissional, se ele entrar na sua casa sem saber "onde fica o disjuntor, qual parede não pode ser derrubada e onde jogar o entulho", ele acabará atrapalhando. O AGENTS.md é esse aviso colado na porta que o Codex lê sempre antes de começar a trabalhar.
Crie um AGENTS.md no diretório raiz do projeto e copie o seguinte conteúdo (curto, preciso e contendo apenas o que realmente será necessário):
# TODO 小工具
一个命令行待办工具，纯 Python 3 标准库，无第三方依赖。
## 运行
- 添加：`python todo.py add <内容>`
- 列出：`python todo.py list`
## 约定
- 只用标准库，不要引入任何第三方包
- 新功能要保持现有命令行风格（`python todo.py <命令> <参数>`）
- 改完必须能用上面的命令跑通
## 测试
- 如果还没有测试文件，用标准库 `unittest` 新建 `test_todo.py`
- 改完跑：`python -m unittest`Lembre-se da dura lição do 〔artigo 11〕 — nunca enterre a única regra útil em cem linhas de conversa fiada. Eu mesmo cometi esse erro no ano passado: escrevi 140 linhas no AGENTS.md e a regra crucial "proibido usar npm" ficou na linha 140. A atenção do Codex já havia sido totalmente diluída pelo conteúdo anterior e ele executou npm install logo em seguida. Por isso, reduzi intencionalmente este aviso a menos de 20 linhas: cada linha é algo que ele realmente usará para este trabalho, sem nenhuma introdução de empresa ou visão de produto.
💡 Resumo em uma frase: O primeiro passo do trabalho é escrever um
AGENTS.mdcurto e preciso, explicando claramente "como rodar, quais as regras e como testar", incluindo apenas o que for realmente útil, sem enrolação.
03 Passo 2: Delegar a Tarefa — Objetivo + Escopo + Restrições + Aceitação, Tudo em Uma Só Frase
Com o aviso pronto, é hora de delegar o trabalho. A qualidade da delegação determina diretamente a precisão do trabalho que ele entregará. Este é o cerne de 〔13 Como Escrever Prompts 〕: com uma frase de conteúdo quase nulo como "adicione uma função de exclusão", ele terá que adivinhar; mas ao detalhar o "conjunto de quatro elementos", ele não sairá dos trilhos.
Analogia: Delegar tarefas é como dar uma ordem de serviço a um pedreiro. Você não pode dizer apenas "reforme este cômodo", deve especificar: como deve ficar (objetivo), qual parede mexer e qual não mexer (escopo), quais materiais usar (restrições) e o que define um trabalho aceito (aceitação). Se faltar um desses quatro elements, o profissional terá que adivinhar por conta própria, e se errar, você terá que refazer o trabalho.
Entre no projeto e inicie uma sessão do Codex:
codexEm seguida, envie a ele esta solicitação estruturada (pode copiar diretamente):
给 todo.py 加一个「删除待办」功能。
目标：支持 `python todo.py done <序号>`，按 list 显示的序号删除对应待办。
范围：只改 todo.py，新增/修改测试文件；不要动命令行整体风格，不要引第三方包。
约束：序号从 1 开始；序号越界或非数字时，打印友好提示而不是报错崩溃。
验收：用 unittest 覆盖「正常删除、越界、非数字」三种情况，`python -m unittest` 全绿。Compare as duas formas de delegar abaixo e a diferença ficará nítida imediatamente:
| ❌ Delegação Vaga | ✅ Delegação Completa (4 Elementos) |
|---|---|
| "Adicione uma função de exclusão" | Formato de comando claro: done <序号> |
| Sem dizer onde mexer ou a extensão da mudança | Escopo definido: mexer apenas em todo.py + testes |
| Sem dizer como tratar limites | Restrições: avisos amigáveis para fora do limite / não numéricos |
| Sem dizer o que define a conclusão | Aceitação: três tipos de casos de teste + unittest tudo verde |
Minha experiência pessoal: colocar o critério de aceitação no prompt é a frase com melhor custo-benefício. No mês passado, pedi ao Codex para adicionar tolerância a falhas em um script de análise. Na primeira vez, com preguiça, não escrevi a aceitação; ele "terminou as alterações", mas o script quebrava diretamente com arquivos vazios. Adicionei "não quebrar com três situações: arquivos vazios, arquivos gigantes e caracteres inválidos" e enviei novamente. Passou de primeira. O limite máximo do Codex é frequentemente definido pela forma como você faz as perguntas.
💡 Resumo em uma frase: Delegue o trabalho descrevendo os quatro elementos "Objetivo + Escopo + Restrições + Aceitação". O que faltar será preenchido pela imaginação do modelo; fixar os critérios de aceitação é o equivalente a dizer "não pare até atingir o padrão".
04 Passo 3: Configurar Permissões — Permitir Alterar Arquivos e Rodar Testes, Mas Sem Deixá-lo Solto
Antes de delegar o trabalho (ou assim que iniciar a sessão), é preciso pensar claramente: o quanto queremos que o Codex altere? Isso faz parte de 〔15 Permissões, Sandbox e Aprovações 〕 — o sandbox controla "o que ele pode acessar" e as aprovações controlam "se ele deve te perguntar antes de agir".
Analogia: Isso é como dar um cartão de acesso a um prestador de serviço. Se a permissão for muito baixa, ele terá que te chamar toda hora para abrir a porta para alterar qualquer coisa, o que é chato; se for muito alta, ele poderá entrar no seu quarto e vasculhar suas gavetas, o que é perigoso. O que queremos para este trabalho é "poder alterar arquivos e executar testes no diretório do projeto, mas sem conseguir sair dessa porta".
Para este trabalho, recomendamos a configuração "escrita no espaço de trabalho + aprovação sob demanda" — o modelo pode modificar livremente os arquivos no diretório do projeto (incluindo criação e exclusão) e pode rodar python -m unittest, mas qualquer ação que ultrapasse os limites, como modificar arquivos fora do espaço de trabalho ou conectar-se à internet, fará com que ele pare e peça sua permissão. Especificação temporária via linha de comando:
codex --sandbox workspace-write --ask-for-approval on-requestOu escreva no arquivo ~/.codex/config.toml para definir como padrão (arquivo de configuração no formato TOML):
# ~/.codex/config.toml
sandbox_mode = "workspace-write"
approval_policy = "on-request"Lembre-se dos três valores padrão cruciais do 〔artigo 15〕 para evitar problemas:
| O que você imagina | Padrão real (sob workspace-write) |
|---|---|
| Ele pode se conectar à internet livremente para baixar pacotes | A rede é desativada por padrão |
O diretório .git pode ser alterado livremente por ele | O .git tem proteção de apenas leitura por padrão |
| Pode fazer alterações em qualquer lugar | Gravável apenas dentro do diretório do espaço de trabalho |
Nunca faça como eu no passado, que para facilitar defini sandbox_mode como danger-full-access no escopo global padrão. No inverno passado, em um diretório temporário que não havia sido inicializado com Git, pedi para ele "limpar arquivos desnecessários". Como no modo de acesso total não havia a barreira do "espaço de trabalho", ele começou a vasculhar direto o meu diretório principal — quando apertei Esc para interromper, senti um frio na espinha. Para este pequeno projeto TODO, o workspace-write é mais do que suficiente. Não solte as rédeas além do necessário.
💡 Resumo em uma frase: Antes de começar, delimite o espaço usando sandbox e aprovações —
workspace-write+on-requestpermitem que ele altere e teste sem sair do diretório do projeto; usardanger-full-accesscomo padrão global é cavar a própria cova.
05 Passo 4: Deixar o Modelo se Autoverificar — Executar Testes e Não Concluir Até Passar
O Codex dizer que "terminou a alteração" não significa que está realmente correto. A forma mais tranquila é deixar que ele execute os testes por conta própria e confirme que estão todos verdes antes de te entregar — você atua apenas como o avaliador final. Este passo coloca em prática os "critérios de aceitação" do 〔artigo 13〕.
Analogia: Isso é como pedir para o chef provar o prato antes de servir. Na delegação de tarefas (Seção 03), você já especificou que "python -m unittest tudo verde" conta como aceitação, o que equivale a entregar uma régua com antecedência. Agora, após alterar, o Codex fará o autoteste seguindo essa régua: executa testes → verifica se está tudo verde → se não estiver, continua alterando. Você não precisa monitorá-lo a cada passo: esperará ele entregar um produto final "já provado e confirmado como correto".
Como incluímos os requisitos de teste no AGENTS.md (a seção ## 测试 na Seção 02) e no prompt ao delegar o trabalho, o Codex geralmente criará ativamente o arquivo test_todo.py e o executará após as alterações. Quando ele rodar os testes, você provavelmente verá algo semelhante no terminal:
...
----------------------------------------------------------------------
Ran 3 tests in 0.003s
OKVer o OK e Ran 3 tests indica que os três tipos de casos fornecidos por ele (exclusão normal, fora dos limites, não numérico) passaram. Caso ele não execute automaticamente, envie uma mensagem cobrando:
跑一下 python -m unittest，把结果贴出来；有不过的就改到全绿再停。Há um detalhe importante aqui plantado na 〔Seção 01〕: como a lista TODOS reside na memória e é limpa ao fim do processo, você não pode testar a lógica de exclusão manualmente via linha de comando usando "primeiro add, depois done, depois list" — a saída do list sempre estará vazia. Portanto, a única forma correta de validar essa funcionalidade é por testes unitários, fazendo add, depois done e validando os resultados no mesmo processo. Isso apenas mostra: trabalhos que exigem testes de autoverificação não devem ser validados de forma simplista com testes manuais visuais.
Tenho uma regra de ouro para mim: sempre que peço para o Codex alterar uma lógica, finalizo com um "execute os testes e cole o resultado". Certa vez, por preguiça, não pedi para rodar os testes, olhei o diff visualmente e achei que estava tudo bem. Como resultado, um caso limite derrubou o ambiente de produção. Desde então, nunca pulo a etapa de "autoverificação".
💡 Resumo em uma frase: Escreva o comando de teste no critério de aceitação ao delegar a tarefa, deixando o Codex executar o
unittestaté ficar tudo verde antes da entrega; lógicas que envolvem estados ou memória devem ser validadas especialmente com testes, sem improvisações visuais.
06 Passo 5 (Opcional): Quando Chamar Subagentes ou MCP para Ajudar
Este pequeno trabalho de TODO pode ser feito tranquilamente por um único agente principal, sem necessidade de subagentes ou MCP. Mas o objetivo de uma prática geral (capstone) é te ajudar a identificar "quando é hora de atualizar seus equipamentos", por isso esta seção esclarece os limites — saber quando não usar é tão importante quanto saber quando usar.
Analogia: Isso é como precisar de ajuda externa na reforma. Para pintar uma única parede, você faz isso sozinho; mas se precisar pintar dez cômodos ao mesmo tempo e consultar uma tabela de cores externa, é hora de chamar ajudantes e consultar materiais de referência. Os subagentes são os ajudantes, e o MCP é o canal de acesso às referências.
Basta lembrar destas duas regras de decisão:
- Tarefas que são "muitas e paralelas" → Chame subagentes. Por exemplo, em vez de remover apenas uma funcionalidade, você precisa alterar em lote sintaxes obsoletas em vinte arquivos. Nesse caso, deixar o agente principal dividir a tarefa e ter múltiplos subagentes trabalhando em paralelo é muito mais rápido do que um único agente trabalhando sequencialmente. Como dividir e delegar é visto em 〔21 Subagentes 〕 — lembre-se do temperamento dele: ele só dividirá a tarefa se você pedir, nunca agirá por conta própria.
- Tarefas que "precisam alcançar o mundo externo" → Conecte o MCP. Por exemplo, se antes de excluir for necessário verificar em um sistema interno da empresa se "esta tarefa já foi arquivada". Esse tipo de capacidade externa que o Codex não consegue alcançar sozinho depende do MCP como uma "interface externa" para ser integrada, veja 〔20 Conectar Ferramentas Externas com MCP 〕.
| A tarefa | Deve atualizar? | Por quê |
|---|---|---|
Adicionar funcionalidade de exclusão ao todo.py | ❌ Não | Alteração simples em arquivo único, o agente principal dá conta |
| Mudar em lote sintaxe obsoleta em 20 arquivos | ✅ Subagentes | Muitas tarefas e executáveis em paralelo, dividir economiza tempo |
| Consultar status de arquivamento no sistema externo antes de excluir | ✅ MCP | O Codex não alcança o ambiente externo, precisa de uma interface |
Para ser sincero, o erro mais comum dos iniciantes não é "deixar de usar quando deviam", mas sim "forçar o uso sem necessidade" — criar cinco subagentes para uma alteração simples de três linhas é pura complicação desnecessária. Conclua o trabalho primeiro com o agente único mais simples possível. Se realmente esbarrar na barreira de "muitas tarefas paralelas" ou "indisponibilidade de acesso externo", aí sim atualize.
💡 Resumo em uma frase: Um único agente principal basta para tarefas pequenas, não force o uso de recursos pesados; use subagentes apenas se houver "muito trabalho paralelizável" (Artigo 21) e conecte o MCP se "precisar acessar o mundo externo" (Artigo 20).
07 Passo Final: Commit com git — Ele Prepara o Rascunho, Você Confirma
Com a funcionalidade correta e todos os testes verdes, o último passo é realizar um commit limpo da alteração. Esta é a especialidade de 〔26 Integração com Git e GitHub 〕, servindo também como o fechamento do fluxo: ele analisa e propõe a mensagem de commit, mas a decisão final de enviar é sua.
Analogia: Isso é como uma "assinatura conjunta" antes de firmar um contrato. Uma parte redige os termos (o Codex olha o diff e escreve a mensagem de commit), e a outra revisa cada ponto antes de assinar (você dá uma olhada e confirma o envio). O commit é a "versão final" que entrará para o histórico, esta etapa exige que alguém tome a decisão, e esse alguém é você.
Diga diretamente na sessão:
把这次改动提交一下：先看 git status 和 git diff，再写一条中文提交信息，前缀用 feat:，提交前把变更和信息列给我确认。O Codex costuma lidar com commits do git seguindo este fluxo:
1. git status —— 看有哪些变更
2. git diff —— 审具体改了什么
3. git add —— 把要提交的加进暂存
4. git commit —— 写好信息、创建提交⚠️ Experimental, sujeito a mudanças: Permitir que o Codex execute o
git commitpor conta própria depende de uma chave experimental chamadacodex_git_commit, que vem desativada por padrão. Portanto, ao seguir este fluxo, a postura mais segura é: deixar o Codex te ajudar a ver o diff e sugerir a mensagem de commit, mas digitar você mesmo o comando finalgit commit— garantindo o rascunho dele, mas mantendo a etapa de "confirmar o envio" sob seu total controle.
Por que o passo git commit tem naturalmente essa barreira? Porque sob o sandbox workspace-write, o diretório .git tem proteção de apenas leitura (como abordado no 〔artigo 15〕). Ações que alteram o commit geralmente exigem sua aprovação prévia. Isso te dá a oportunidade perfeita para revisar: se os arquivos alterados estão corretos, se a mensagem de commit faz sentido e se nada indesejado (como arquivos temporários) está sendo enviado junto. Após confirmar tudo, dê o sinal verde. Você pode esperar uma mensagem de commit semelhante a esta:
feat: 新增按序号删除待办功能并补充 unittest 用例Depois do commit, faça você mesmo uma verificação final para maior segurança:
git log --oneline -1Saída esperada (o hash no seu computador será diferente, o que é normal):
a1b2c3d feat: 新增按序号删除待办功能并补充 unittest 用例Meu hábito real é: nunca deixar o git commit no modo "totalmente automático" para rodar sem supervisão. A linha vermelha que atravessa todo este livro — "o modelo revisa, você autoriza" — fica mais evidente nesta etapa de commit. Não por medo de que ele erre a mensagem, mas sim de que inclua códigos inacabados que não percebi no histórico. Limpar isso depois custa muito mais caro do que dar uma olhada na hora.
💡 Resumo em uma frase: Deixe o Codex preparar o rascunho do commit (revisar diff, sugerir mensagem), mas execute você mesmo a confirmação do
git commit— esse é o ponto de fechamento da diretriz principal do livro: "o modelo revisa, você autoriza".
08 Revisão do Fluxo Completo: Qual Habilidade de Qual Artigo Está Sendo Usada em Cada Passo
Ao terminar o processo e analisar esse fluxo como um todo, você verá que os mais de trinta artigos anteriores não são pontos de conhecimento isolados, mas etapas em uma linha de montagem. Você poderá aplicar esta tabela diretamente em qualquer projeto futuro:
| Passo | O que é feito nesta etapa | Artigo Correspondente |
|---|---|---|
| ① Definir o Alvo | Criar a versão mínima executável de todo.py e colocá-la no Git | Este artigo |
| ② Escrever Avisos | AGENTS.md detalhando contexto, execução e regras | 〔11 〕 |
| ③ Delegar a Tarefa | Objetivo + Escopo + Restrições + Aceitação descritos por completo | 〔13 〕 |
| ④ Configurar Permissões | workspace-write + on-request delimitando o espaço | 〔15 〕 |
| ⑤ Atualizar (Se necessário) | Muitas tarefas paralelas exigem subagentes; acessar mundo externo exige MCP | 〔21 〕〔20 〕 |
| ⑥ Autoverificar | Deixar rodar o unittest até ficar tudo verde antes da entrega | 〔13 〕 |
| ⑦ Commit | O Codex propõe o diff e a mensagem, você confirma e realiza o commit | 〔26 〕 |
A ordem deste fluxo não foi decidida de forma aleatória, mas segue o ritmo natural de um desenvolvimento real: primeiro fazer o modelo entender o projeto (avisos), depois especificar o que queremos (delegar a tarefa), em seguida delimitar as permissões de alteração (permissões), testar após a conclusão (testes) e, por fim, guardar o trabalho no repositório (commit).
Qual modelo escolher e qual intensidade de raciocínio configurar? Neste fluxo, usei a configuração padrão — modelo topo de linha gpt-5.5 + intensidade de raciocínio padrão (geralmente medium), o que é totalmente suficiente para esta pequena tarefa de TODO, sem a necessidade de aumentar para high. Se você enfrentar desafios maiores, como uma "grande refatoração entre módulos", consulte novamente o 〔30 Como Escolher Modelos 〕 para ajustar conforme o cenário. Neste artigo, fiz questão de seguir com as configurações padrão o tempo todo para que você veja claramente: o fluxo em si é o protagonista, e o ajuste de parâmetros é apenas um complemento.
💡 Resumo em uma frase: Avisos → Delegar a tarefa → Permissões → (Atualizar se necessário) → Autoverificar → Commit: esta ordem representa o ritmo natural do desenvolvimento real. Cada artigo anterior é uma etapa nesta linha de montagem, e somente ao juntá-las você estará realmente "dominando o Codex".
Resumo
Este artigo não ensinou novas funções, mas sim "como montar as peças em uma máquina funcional":
- Definir o Alvo: criar manualmente a versão mínima executável de
todo.pye colocá-la no Git, permitindo que cada etapa seguinte tenha um propósito claro. - Escrever Avisos: criar um
AGENTS.mdcurto e preciso, incluindo apenas o que realmente for útil, sem diluir as regras principais. - Delegar a Tarefa: detalhar os quatro elementos "Objetivo + Escopo + Restrições + Aceitação", definindo os critérios de aceitação como "não parar até atingir o padrão".
- Configurar Permissões: limitar o espaço com
workspace-write+on-request, evitando o uso dedanger-full-accesscomo padrão global. - Autoverificar: deixar o modelo rodar o
unittestaté ficar tudo verde. Lógicas de estados devem ser validadas especialmente com testes, sem improvisações visuais. - Commit: o Codex prepara o rascunho, você confirma. A diretriz principal "o modelo revisa, você autoriza" se concretiza nesta etapa de fechamento.
Agora você deve ser capaz de: diante de qualquer pequena demanda, evitar agir sem planejamento. Em vez disso, siga o fluxo "Avisos → Delegar a tarefa → Permissões → Autoverificar → Commit", integrando as peças aprendidas anteriormente em um desenvolvimento limpo, reproduzível e seguro. Essa é a verdadeira linha divisória entre "saber usar o Codex" e apenas "ter ouvido falar do Codex".
No próximo artigo 〔35 Guia Rápido de Comandos e Configurações 〕, reuniremos todos os comandos, chaves de configuração e comandos de barra comuns do módulo Codex em uma tabela de consulta rápida a qualquer momento. Como você acabou de me acompanhar nesta prática, aproveite o momento para refletir: neste fluxo, quais comandos você consegue digitar de cabeça sem errar na próxima vez e quais ainda precisará consultar? Essa tabela foi preparada justamente para a parte que você "ainda precisará consultar".