wechat-article

Codex アダプターに関する注記

このスキルは skills/wechat-article.md から生成されており、Claude Code と Codex のユーザーが同じ標準ワークフローを共有できます。

• $ARGUMENTS は、現在の Codex スレッドにおけるユーザーのリクエストとして扱います。
• ソースに Task、Agent、WebSearch、Bash、Read、Write など Claude 専用の機能が記載されている場合は、このセッションで利用可能な最も近い Codex の機能を使用します。利用可能であればサブエージェントを使い、必要に応じてウェブ検索を行い、ローカルツールにはシェルコマンドを使い、ワークスペースのファイルは通常のファイル編集で対応します。
• このリポジトリの tools/ にある共有プロジェクトツールを使用します。リポジトリのルートから python3 tools/financial_rigor.py ... のようなパスでコマンドを実行することを推奨します。現在のスレッドがリポジトリ外から始まった場合は、固定のホームディレクトリパスを前提にせず、まず実際のチェックアウトパスを探してください。
• 調査を始める前に date コマンドを実行して今日の日付を確認し、「最新」データの基準として扱い、レポートのヘッダーにデータの基準日を記載します。学習データから現在の日付を推測してはいけません。
• AGENTS.md の調査品質ルールを遵守します。財務データを相互検証し、評価や数学の計算には正確な算術ツールを使い、不確実性や情報源の不足を明確に示します。

WeChat 公式アカウント記事：著者・編集者・読者の3エージェント協業

$ARGUMENTS を深く調査し、そのまま公開できる WeChat 公式アカウント記事を作成します。3つのエージェントがそれぞれ役割を担います。著者が内容の深い初稿を書き、編集者が構成と表現を磨き、読者が対象読者の視点からレビューします。

対応する入力形式：テーマの説明。例：大模型OPD技术解读、Qwen3技术报告解读、为什么巴菲特不买科技股

---

設計理念

優れた WeChat 公式アカウント記事は、次の3つの要素を同時に満たす必要があります。

1. 深さ——時間をかけて最後まで読んだ人に応える内容（著者が担当）
2. 読みやすさ——構成が明快でテンポがよく、読む気を失わせないこと（編集者が担当）
3. 本当に理解できること——対象読者が途中で読むのをやめないこと（読者が担当）

一人で書くと「自分だけが盛り上がる」文章になりがちです。書く人には明快に思えても、読む人には理解できないことがあります。3エージェント協業の本質は、外部の視点を強制的に取り入れることです。

---

フェーズ1：調査と素材の収集

ステップ1：記事の位置づけを明確にする

執筆を始める前に、以下の情報を確認します（ユーザーから指定がない場合は、こちらから尋ねます）。

項目	確認する内容	デフォルト値
対象読者	技術的な背景の程度	多少の技術的な背景はあるが、その分野の専門家ではない
記事の深さ	入門／中〜高程度／専門的	中程度（数式を使うが、分かりやすく説明する）
記事の長さ	文字数の範囲	3000〜4000字
原論文・資料のダウンロードが必要か	PDF／図の必要性	はい
文体	フォーマル／対話調／鋭い表現	対話調（賢い友人に向けて書くように）

ステップ2：詳細な調査

Agent ツールを使い、調査エージェントを2〜3個並行して起動し、十分な素材を集めます。

調査エージェントA：中心テーマの調査

• 論文の解説の場合：論文のPDFをダウンロードし、中心的な貢献、重要な図表、実験結果を抽出します
• 技術テーマの場合：最新の動向、重要な論文、技術的な詳細を調べます
• ビジネス／投資テーマの場合：最新のデータ、業界レポート、競争環境を調べます

調査エージェントB：業界の背景と応用

• その技術／テーマが業界でどのように実用化されているかを調べます
• どの企業が採用しているか、その効果はどうかを調べます
• 最新の発展傾向と節目となる出来事を調べます

調査エージェントC（任意）：競合／比較調査

• 同種の手法／製品を比較します
• 歴史的な発展の経緯を整理します
• 今後の進化の方向性を調べます

ステップ3：素材の構成を整理する

すべての調査エージェントが作業を終えたら、以下を整理します。

1. 中心的な論点（記事で伝える中心的なメッセージを一文で要約）
2. 重要なデータ（最もインパクトのあるデータポイントを3〜5個）
3. 図のリスト（必要な図とその出典）
4. 記事の構成案（6〜8章の見出しと中心的な内容）

---

フェーズ2：著者エージェントが初稿を執筆

Agent ツールを使って著者エージェントを起動し、詳細な執筆指示を伝えます。

著者エージェント向けプロンプトのテンプレート

你是一位深度技术写作者（Author Agent），需要写一篇微信公众号文章。

## 目标读者
{根据第一步确认的读者画像}

## 写作风格要求
- 纯中文表达，避免中英文夹杂（技术术语首次出现时给英文，后续用中文）
- 像写给聪明的朋友看的技术科普，不是学术论文翻译
- 用类比帮助理解，但类比要贴切、不俗套
- 关键公式/数据要有，但每个都要用大白话解释
- 不用emoji
- 段落不超过4行（公众号阅读环境）

## 核心内容
{整理好的素材、数据、论点}

## 文章结构要求
1. **开头（前3段）**：必须有强钩子——用数据冲击力或反直觉的结论开场，不要用温和的类比开场
2. **背景**：为什么这件事重要？解决什么问题？
3. **核心内容（2-3节）**：技术深度在这里体现，但每个技术点都要有"大白话翻译"
4. **实证/案例**：用数据和案例说话，不要空谈
5. **行业影响/展望**：这件事对行业意味着什么
6. **结尾**：一句有传播力的判断收束，适合被截图转发

## 配图要求
- 论文解读类文章：必须从论文PDF中提取原图，直接用 `![描述](相对路径)` 插入文章，不要用 [图X：描述] 占位符
- 提取方法：用 pdftoppm 将PDF页面渲染为高分辨率PNG（至少900 DPI），再用 PIL 裁切目标图表区域
- 每张图不小于500KB，确保高清
- 图片统一存放在 `assets/{主题简称}/` 目录下
- 非论文类文章：如需配图，搜索并下载合适的图片，同样直接插入

## 公式要求
- 所有数学公式使用 LaTeX 格式：行内用 `$...$`，独立公式用 `$$...$$`
- 禁止用纯文本写公式（如 `> D_KL(P || Q) = ...`），必须用 LaTeX 渲染格式
- 每个公式后面仍然要配"大白话翻译"

请写出完整的文章初稿，约{目标字数}字。

著者エージェントの作業完了後

初稿ファイルが生成されていることを確認し、内容に不足がないか本文をすべて読んで確認します。

---

フェーズ3：編集者エージェントと読者エージェントによる並行レビュー

初稿が完成したら、Agent ツールを使って、同じメッセージ内で編集者エージェントと読者エージェントを起動します。

編集者エージェント向けプロンプトのテンプレート

你是一位资深公众号编辑（Editor Agent）。请对以下文章进行精修审阅。

## 审阅标准
1. **标题**：是否在朋友圈能吸引点击？是否会被截断（超过30字）？
2. **开头**：前3段能否留住读者？钩子是否足够强？
3. **结构**：逻辑链是否流畅？有无跳跃或断层？
4. **深度与可读性平衡**：公式/技术部分是否真的通俗？有无"假装通俗但没解释清楚"的地方？
5. **节奏**：有无太长的段落？每节长度是否合适？
6. **配图**：图片是否已实际插入（非占位符）？位置是否在读者最需要视觉辅助时出现？
7. **结尾**：有无传播力？读者看完会想转发吗？

## 文章全文
{完整初稿}

## 输出格式
1. 总体评价（3-5句话）
2. 标题修改建议（给2-3个备选）
3. 逐节修改建议（给出"原文→建议修改为"的具体对照）
4. 最关键的3个改进点

読者エージェント向けプロンプトのテンプレート

你是一位{目标读者画像}（Reader Agent）。请从读者视角审读以下文章。

## 你的背景
{具体描述目标读者的知识水平和阅读习惯}

## 文章全文
{完整初稿}

## 请回答以下问题
1. 读完前3段，你会继续读下去吗？为什么？
2. 哪些地方"看不懂"或"需要重读才能理解"？具体是哪句话？
3. 技术/公式部分你看懂了吗？"大白话翻译"是否帮到你了？
4. 文章的核心类比贴切吗？有更好的类比吗？
5. 太长还是太短？会在哪里失去耐心？
6. 读完后你能用一句话概括文章核心观点吗？
7. 你会转发这篇文章吗？转发时你会说什么？
8. 有没有你想了解但文章没覆盖的问题？

---

フェーズ4：最終稿

ステップ1：2つのエージェントからのフィードバックを統合する

特に、頻繁に指摘される以下の問題に注目します。

問題の種類	編集者によくある指摘	読者によくある指摘	対応方法
書き出しが弱い	フックが弱すぎる	最初の3段落を読んでも先を読む気にならない	データや直感に反する結論を使って書き出しを書き直す
技術的な説明で読む気が失せる	数式が多すぎる	ある段落を3回読み直す必要がある	数式を削るか図に置き換え、より直感的な比喩を加える
テンポが悪い	ある節が長すぎる	ある箇所で読むのに飽きてしまう	統合または削減する（特に後半で繰り返される技術的な説明）
結びが弱い	拡散力がない	シェアする気にならない	スクリーンショットで共有できる一文の判断に書き直す
概念のつながりが飛躍している	論理に飛躍がある	ある箇所で「急に分からなくなった」	つなぎの文や背景説明を補う

ステップ2：修正を行う

フィードバックに基づいて記事を書き直します。修正の基本方針は次のとおりです。

1. 編集者と読者の両方が指摘した問題は、必ず修正します
2. 編集者だけが指摘した問題も、ほとんどの場合は修正します（編集者の専門的な判断は通常正確です）
3. 読者だけが指摘した問題は、状況に応じて修正します（読者のフィードバックは実際の読書体験を反映していますが、すべてに対応する必要があるとは限りません）
4. 両者の意見が矛盾する場合は、読者を優先します（編集者は完璧さを追求しますが、最終的な基準は読者の体験です）

ステップ3：図を抽出する

論文解説の記事では、最終稿を作る前に必ず図を抽出します。

1. レンダリング：pdftoppm -png -r 900 -f {页码} -l {页码} 论文.pdf /tmp/page（まず900 DPIでレンダリングします。画像が500KB未満の場合は1200または1500 DPIに上げます）
2. 位置の特定：まず150 DPIでページ全体をレンダリングし、目視で各図表のピクセル座標を確認します
3. 切り抜き：PILを使って座標に基づき切り抜き、compress_level=1 で保存します。各画像が500KB以上になるようにします
4. 保存：assets/{主题简称}/ ディレクトリに、fig{序号}-{描述}.png という名前で保存します
5. 挿入：記事内で ![描述](../../assets/{主题简称}/fig{序号}-{描述}.png) を使って参照します

ステップ4：最終ファイルを作成する

最終稿を md ファイルとして保存し、ファイルの末尾に論文／資料の原文リンクを付けます。

**论文原文：**
- arXiv: {链接}

---

ファイル名と保存場所

種類	パス	命名形式
技術テーマ	reports/AI产业研究/	公众号-{主题关键词}-{YYYYMMDD}.md
投資テーマ	reports/{公司名}/	{公司名}-公众号-{YYYYMMDD}.md
一般テーマ	reports/	公众号-{主题关键词}-{YYYYMMDD}.md

---

写作红线

1. 不虚构数据。引用的数据必须有来源，搜不到就标注"估计"
2. 不用AI腔调。禁止"让我们一起来看看"、"值得关注的是"、"不得不说"等套话
3. 不过度承诺。技术文章不说"颠覆性的"、"革命性的"，用数据说话
4. 公式必须配大白话。每个公式后面都要有一段"翻译成人话就是……"
5. 公式必须用LaTeX。$$...$$ 格式，禁止纯文本公式
6. 配图必须实际插入。论文解读类从PDF提取高清原图（≥500KB），禁止用 [图X] 占位符
7. 表格括号注释要精确。描述概念时用准确的定义，不用模糊的动宾短语（如"文本来自教师"而非"学教师的文本"）
8. 类比要一以贯之。全文用一个主线类比，不要每节换一个新类比
9. 结尾必须有传播力。最后一句话要值得被单独截图转发