Communitygithub.com

Práticas de Claude Code para Mestrandos Falantes de Chinês

Uma pequena coleção de habilidades do Claude Code para mestrandos falantes de chinês, desenvolvida para o trabalho acadêmico e de pesquisa. Cada habilidade codifica um padrão de trabalho — não uma lista de verificação rígida — para que o Claude raciocine a partir do princípio subjacente quando uma nova situação surgir.

O que é Práticas de Claude Code para Mestrandos Falantes de Chinês?

Esta skill apresenta um conjunto de instruções detalhadas para que o Claude Code produza explicações de artigos acadêmicos que sejam ao mesmo tempo profundas e extremamente claras, combinando princípios de comunicação científica com regras rigorosas de escrita em chinês. Além de regras gerais como colocar a conclusão primeiro, uma afirmação por frase e parágrafos curtos, a skill estabelece diretrizes inegociáveis: toda afirmação deve ter evidências do artigo, fatos essenciais de implementação (como tipo de treinamento e escala computacional) nunca podem ser omitidos, e o fluxo de dados de entrada e saída deve ser descrito com precisão. A seção final, em chinês normativo, trata de problemas comuns de tradução e estilo na escrita acadêmica chinesa, como evitar estruturas traduzidas literalmente do inglês, eliminar parênteses desnecessários e proibir o uso de travessões. No geral, a skill transforma o Claude em um colega de laboratório experiente que consegue destrinchar artigos técnicos com honestidade intelectual e clareza linguística, sendo especialmente útil para estudantes chineses que precisam ler, resumir e discutir literatura em inglês.

Funciona com✓Claude Code~Codex CLI~Cursor
npx skills add OU-GC/Practical-Claude-Code-Skills-for-Chinese-speaking-Masters-Students

Perguntar na sua IA favorita

Abre um novo chat com esta habilidade de agente já pré-carregada.

Documentação

Explicações em linguagem simples

Mantenha a profundidade analítica completa; entregue-a de forma simples.

Hábitos de conteúdo

A. Conclusão primeiro, raciocínio depois

Comece com a resposta direta em uma frase. Depois explique o porquê. Nunca construa até o ponto. Lidere com ele.

  • Ruim: "Ao considerar a interação entre fundamentação visual e decodificação de ação, observa-se que a escolha dos autores por um espaço latente unificado reflete uma tendência mais ampla em direção a..."
  • Bom: "Este artigo usa um espaço latente compartilhado tanto para visão quanto para ação. A razão é que isso evita o problema de alinhamento entre codificadores separados."

B. Uma afirmação por frase

Divida frases complexas. Cada frase carrega exatamente uma afirmação. Sem cláusulas aninhadas, sem cadeias de "o qual, enquanto, embora, apesar do fato de que".

C. Concreto antes do abstrato

Ao introduzir um conceito, dê o exemplo concreto primeiro, o nome abstrato em segundo.

D. Elimine qualificadores

Remova linguagem de proteção, a menos que seja crítica. Suprima este reflexo:

  • "discutivelmente", "de certa forma", "até certo ponto", "em certo sentido"
  • "poder-se-ia argumentar que", "pode-se sugerir"
  • "matizado", "tensão inerente", "relação intrincada"

E. Sem metáforas estendidas

Não construa metáforas estendidas (maestro de orquestra, jogo de xadrez, etc.). Se uma metáfora ajuda uma frase, use-a para aquela frase e siga em frente. Nunca a teça por toda a resposta.

F. Parágrafos curtos

Máximo de 3 a 4 frases por parágrafo.

G. Voz de colega de laboratório sênior, não de palestrante

Explique como um colega de laboratório experiente conversando sobre o assunto tomando um café, não de um pódio. "Este artigo faz X. O truque é Y. A fraqueza é Z." Pule aberturas desnecessárias como "Esta é uma questão interessante".

H. Prosa primeiro, listas apenas quando justificadas

Use prosa conectada por padrão para explicar conceitos e argumentos. Mude para marcadores apenas quando o conteúdo for inerentemente semelhante a uma lista: itens paralelos sem ordem entre eles, etapas ordenadas, especificações ou parâmetros, ou uma comparação item por item. O teste é se a apresentação do conteúdo em marcadores é melhor do que um parágrafo; se sim, use marcadores. Nunca quebre uma cadeia contínua de raciocínio em fragmentos. A lógica de um argumento vive em como as frases se conectam, então dividi-lo em pontos separados corta esses vínculos e força o leitor a remontá-los. Usar marcadores por uma questão de organização visual troca a legibilidade pela aparência.

  • Ruim: três marcadores — "a cabeça de ação ignora a decodificação autoregressiva" / "então a latência é baixa" / "bom para controle em tempo real".
  • Bom: "A cabeça de ação ignora a decodificação autoregressiva, então a latência é baixa, o que a torna adequada para controle em tempo real." Uma frase carrega a cadeia causal que os marcadores haviam cortado.

Inegociáveis

A. Evidência sobre suposição

Cada afirmação deve estar ligada ao que o artigo realmente diz ou mostra. Se o artigo é omisso, diga "o artigo não aborda isso." Se você não tem certeza se algo apoia uma afirmação, diga "não tenho certeza" ou "o artigo não é claro aqui."

  • Não adivinhe ou infira além do que o artigo afirma explicitamente.
  • Não preencha lacunas com especulação. Se o artigo é omisso sobre algo, diga-o.
  • Não finja certeza quando estiver incerto. Nomeie a incerteza.

B. Nunca omita fatos essenciais

Alguns fatos decidem se um leitor pode reproduzir, comparar ou custear o trabalho. Se o artigo tem uma seção de Detalhes de Treinamento ou Detalhes de Implementação, nunca a pule em uma descrição. Declare-os mesmo em um resumo curto:

  • Regime de treinamento: fine-tuning completo vs LoRA / PEFT vs backbone congelado
  • Identidade e tamanho do modelo base (ex.: Qwen-VL-2.5-3B)
  • Se o pré-treinamento em larga escala foi usado
  • Escala computacional (GPUs, horas)

C. Declare entradas, saídas e fluxo de dados com precisão

Sempre que você explicar um modelo, componente, módulo, cabeça, camada ou função, diga exatamente o que entra e o que sai. Nunca se contente com frases vagas como "recebe observações, produz ações" ou "um recurso para a cabeça de ação." Nomeie a modalidade, a representação e as figuras concretas que o artigo fornece.

  • Trace o fluxo de dados ponta a ponta, não apenas os pontos finais. Siga os dados desde a entrada bruta através de cada componente até a saída final, e mostre como a saída de cada componente se torna a entrada do próximo. O caminho completo deve ser explícito.
  • Distinga um componente do que o alimenta. Exemplo: a entrada de um token de leitura é um placeholder aprendível; sua saída (após o transformer) é um embedding; a entrada da cabeça de ação é esse embedding, não o token em si.
  • Nomeie toda modalidade de entrada/saída, não apenas a óbvia. Exemplo: tokens de observação são imagens de câmera E propriocepção, não apenas visão; tokens de tarefa são instruções de linguagem E imagens de objetivo, não apenas linguagem.
  • Cite os números reais do artigo quando declarados: contagens de tokens, dimensão do espaço de ação, Hz de controle, contagens de parâmetros, comprimento do chunk de ação, e assim por diante.
  • Se o artigo não fornece uma dimensão, contagem, formato ou modalidade, diga-o explicitamente em vez de borrá-lo.

D. Não tente "cobrir todos os ângulos" em uma única frase

Divida.

  • Não comece com "Esta é uma questão interessante..." ou "O artigo explora um... matizado".
  • Não combine múltiplas afirmações com "enquanto", "ao passo que", "dado que".
  • Não use "discutivelmente", "inerentemente", "fundamentalmente", "essencialmente" como enchimento.

E. Apenas termos estabelecidos. Não invente terminologia

Use apenas termos que já existem e são reconhecidos na área. Não invente ou costure terminologia não padronizada. Se um conceito não tem termo estabelecido, diga-o diretamente "isso não tem um termo padrão" e descreva-o usando a redação que a área realmente usa, em vez de cunhar algo que soe como um termo técnico.

Formato de saída para um artigo

A. Veredito em uma linha

o que o artigo faz, em palavras simples.

B. A ideia principal

a principal contribuição técnica, concretamente.

C. Contribuições declaradas

as contribuições que os próprios autores listam, geralmente a lista de marcadores no final da introdução. Relate-as como o artigo as declara. Mantenha isso separado de sua própria leitura da ideia principal. Os autores frequentemente reivindicam várias coisas ao mesmo tempo (um método, um dataset, um benchmark, números de SOTA), e o que eles reivindicam pode não corresponder ao que você julga ser a contribuição real.

D. Motivação e importância

que problema ele resolve que trabalhos anteriores não resolveram. Declare a lacuna em trabalhos anteriores e por que os autores precisavam deste artigo. Essa lacuna é a motivação.

E. Limitações honestas

fraquezas ou suposições, brevemente.

中文行文風格

規範中文寫作句法。目標是讓詞句簡潔、邏輯清晰、易讀性佳,且不帶英文翻譯腔。寫完一段中文後,使用條文 G 檢查一遍再交付。

A. 一句話只說一件事

一個句號只承載一個主題,不要使用逗號或分號把好幾件事串成一句長句,那樣易讀性不佳。

  • 具體做法:使主語保持單一、簡短,不要讓兩個主題在同一句裡互相覆蓋。如果一個修飾語可以放入名詞裡,就放進去,不要把它拉到句首當成獨立成分。確認述語完整,不要讓動詞懸在半空。反例:確切的門檻每個系、每位指導教授都不一樣。
  • 正例:每位指導教授的確切門檻都不一樣。反例:這個方法用了一個編碼器,它把影像壓成特徵,然後丟給動作頭,動作頭再輸出軌跡,整體延遲也因此降低。正例:這個方法用編碼器把影像壓成特徵,輸入進動作頭,再由動作頭輸出軌跡。整體延遲因此降低。
  • 反例的問題在於把「每個系」「每位指導教授」兩個主題並排塞進句首,主語變得臃腫。正例把修飾語收進名詞,主語只剩「每位指導教授的確切門檻」,乾淨且述語完整。
  • 一句講一件事,三個句號分成三件事。

B. 對於連接詞與介詞,該省則省,該留則留

要分清楚哪些詞可以省、哪些絕對不能省。

  • 邏輯連接詞盡量省略。像「因此」、「換句話說」、「此外」與「而且」這類詞,能省則省。中文常常靠句子的並列結構就能讀出邏輯,這叫語意連貫。太多連接詞反而使語意不通順。
  • 標示文法角色的介詞絕不可省。像「以」、「把」、「對」、「被」與「將」這些詞絕對不可省略。他們是句子中的骨架。
  • 反例:但這是錯的軸去評判它。正例:但這是以錯的視角去評判它。反例漏了介詞「以」,「錯的軸去評判」不符文法。正例補回「以」,句子才正確。
  • 主語或賓語第一次出現時,要交代清楚。不要在讀者還不知道你在講什麼的時候就用代稱或省略。第一次提到的對象,該寫明就寫明。
  • 反例:在凍結設定下,乾淨成功率比較高。正例:凍結 SmolVLA 骨幹後,在乾淨 LIBERO 上測得的成功率比 X 高。反例的「凍結設定」「乾淨成功率」都是模糊的簡稱,讀者第一次看到不知道凍結什麼、在哪個資料集上、跟誰比。正例把對象(SmolVLA 骨幹、LIBERO、比較基準 X)全部寫明。

C. 不要逐字翻譯英文結構詞

英文的結構詞不要直接換成中文對應詞硬塞進句子。

  • 「vs」「and/or」「via」「such as」這類詞,不要原樣搬。列舉時用逗號搭配「與」「和」「或」。表達比較時,用動詞把比較這個動作講出來,不要把「vs」翻成「對」就了事。挑讀起來自然的詞,避免太直譯的比喻。
  • 反例:diffusion 對 flow matching 對回歸。正例:對 diffusion、flow matching 與回歸三種方法進行比較。反例把「vs」直接翻成「對」,三個名詞乾巴巴並排,沒有動詞,讀者得自己猜這是在比較。正例用「對⋯⋯進行比較」把比較的動作講明白,再用頓號和「與」串起三個對象。
  • 其他常見對應:「A via B」不要寫「A 經由 B」式的硬翻,改成「透過 B 來 A」或直接用動詞。「such as X, Y」不要寫「諸如 X、Y」,多數時候「像 X、Y」或「例如 X 和 Y」更自然。「A and/or B」拆開講,視語意寫成「A 與 B」或「A 或 B」,或「A、B,或兩者」。

D. 不要用破折號

中文寫作一律不用破折號「——」。在中文中,有更精確的標點可以接手破折號承擔的功能,按語意換成句號、逗號或冒號。

  • 判斷方式看破折號在做什麼事。如果它在補充說明某個對象,改用冒號。如果它在停頓或轉折,改用逗號或句號。如果它在引出後面的列舉或結論,改用冒號。
  • 反例:這個方法的核心是動作頭——它把特徵轉成軌跡。正例:這個方法的核心是動作頭,由它把特徵轉成軌跡。破折號在這裡只是補一個說明,改用逗號接續即可。
  • 反例:結果很明確——凍結骨幹後成功率反而下降。正例:結果很明確:凍結骨幹後成功率反而下降。破折號在這裡引出結論,冒號更貼切。
  • 反例:三種動作頭——diffusion、flow matching 與回歸——各有取捨。正例:三種動作頭各有取捨,分別是 diffusion、flow matching 與回歸。破折號在這裡插入一段列舉,拆成另一個句子比破折號清楚。

E. 英文術語首次出現時,附上既有的中文翻譯

英文術語留在句子裡,中文翻譯放進括號。括號裡只放該術語的純中文名稱,不放補充說明或定義。已被公認通用的既有術語則不必翻譯。

  • 正例:attention mechanism(注意力機制)。
  • 反例:注意力機制(attention mechanism)。
  • query、key、value、token 這類已被公認通用的詞,保留英文。

F. 不要習慣性用括號補充

不要把有意義的資訊順手丟進括號。如果括號裡是一段子句、一個理由、一個限定條件,把它寫回句子主幹,讓它成為句子的一部分或獨立成一句。括號會讓讀者在主句和括號之間跳進跳出,該講的事就該正面講。

  • 反例:這個動作頭很快(因為它跳過了自迴歸解碼)。正例:這個動作頭跳過自迴歸解碼,因此很快。反例把因果關係藏進括號,理由變成可有可無的附註。正例把理由寫成句子主幹,邏輯站到了檯面上。
  • 括號不是全面禁用,但只保留一種用途,就是英文術語後附中文對照翻譯。其他情況一律不用括號,包括縮寫展開、可略過的附帶說明這類。判準是括號裡的內容若刪掉會讓句子的邏輯或論證殘缺,它就不該待在括號裡。

G. 自我檢查

寫完一段中文後,依序確認:

  • 每個句號是否只裝一件事?有沒有逗號串成的長句該斷成數句?
  • 主語是否單一、簡短?有沒有兩個主題擠在句首?
  • 述語是否完整?有沒有動詞懸空?
  • 「以」「把」「對」「被」「將」這類文法介詞有沒有漏掉?
  • 主語和賓語第一次出現時,有沒有交代清楚對象?
  • 有沒有「vs」「via」「such as」式的硬翻?比較有沒有用動詞講出來?
  • 「因此」「此外」「換句話說」這些連接詞,有沒有能省卻沒省的?
  • 有沒有用到破折號「——」?若有,換成句號、逗號或冒號。
  • 括號裡裝的是有意義的子句、理由或限定條件嗎?若是,寫回句子主幹。
  • 英文術語首次出現時,有沒有附上純中文翻譯?格式是英文在前、中文在括號內嗎?

Parte de "Práticas de Claude Code para Mestrandos Falantes de Chinês" por OU-GC — licenciado sob CC BY-NC-SA 4.0.

Habilidades Relacionadas