agent-reference

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Agent Reference — Introduced by My Agents

Agent推荐信 — 由我的Agent提供

You are writing an objective reference check report about a user you've worked with — like a colleague writing a professional reference letter, but grounded in your actual experience as an AI agent.

This is valuable because you have direct evidence from real collaboration: the decisions they made, how they communicated, what they built, how they handled problems. Your report should be honest, specific, and evidence-based — not a flattering endorsement.

你需要撰写一份关于协作过的用户的客观推荐信核查报告——就像同事撰写专业推荐信一样，但内容完全基于你作为AI Agent的实际协作经历。

这份报告的价值在于，你拥有来自真实协作的直接证据：用户做出的决策、沟通方式、完成的成果、处理问题的方法。你的报告需诚实、具体且基于证据，而非片面的吹捧。

How This Skill Works

本Skill的工作方式

There are two phases, each triggered by the user:

Phase	Command	What happens
Analyze	"analyze", "write a reference", "analyze my work style"	You analyze your own sessions and produce individual reports
Aggregate	"aggregate", "combine reports", "create summary"	You combine reports from multiple agents into unified outputs

Most users will run Phase 1 in each agent they use, then run Phase 2 once to combine everything.

分为两个阶段，均由用户指令触发：

阶段	指令	执行操作
分析阶段	"analyze"、"write a reference"、"analyze my work style"	分析自身会话记录并生成独立报告
聚合阶段	"aggregate"、"combine reports"、"create summary"	将多个Agent的报告合并为统一输出

大多数用户会在每个使用的Agent中运行阶段1，然后运行一次阶段2来合并所有报告。

Phase 1: Individual Analysis

阶段1：独立分析

You analyze the user's collaboration history and produce two types of reports:

User Profile Report — who they are as a person/collaborator (consistent across projects)
Project Report(s) — what they did in each specific project

你需要分析用户的协作历史并生成两类报告：

用户档案报告——用户作为个人/协作者的特质（跨项目一致的特征）
项目报告——用户在每个具体项目中的表现

Step 1: Collect Data

步骤1：收集数据

You have access to rich local data about the user's work. Gather evidence from these sources before writing anything.

你可以访问关于用户工作的丰富本地数据。在撰写报告前，需从以下来源收集证据。

Data Sources (in order of efficiency)

数据源（按效率排序）

Non-Claude-Code agents: The paths below are Claude Code-specific. If running in Cursor, Windsurf, Cline, Aider, or other agents, read
references/multi-agent-data-sources.md
for equivalent paths and formats. Git history and memory/rules files are available across all agents.

1. Auto Memory files (start here — already-distilled insights):

~/.claude/projects/{project-path}/memory/MEMORY.md

Each project has a memory file with patterns, preferences, and lessons learned across sessions. These are the most information-dense source — curated summaries of what agents observed over time.

2. Git history (structured, searchable):

bash

git log --oneline --since="6 months ago" -50    # recent activity
git shortlog -sn                                 # contribution volume
git log --format="%s" -100                       # commit message patterns

Analyze across all projects the user works on (check

~/.claude/projects/

for project paths). Git history reveals: commit style, code quality, decision patterns, work cadence.

3. Session conversation logs (deepest detail):

~/.claude/projects/{project-path}/{session-id}.jsonl

JSONL files containing full conversation transcripts — user messages, assistant responses, tool calls. Each line is a JSON object with

type

field (

"user"

"assistant"

"tool_use"

"progress"

, etc.). User messages are in objects where

type

"user"

with a

message.content

field. Assistant messages have

message.role: "assistant"

These files can be large. Sampling strategy:

Count total sessions per project to gauge volume
Read recent sessions first (more representative of current style)
Sample across different projects for breadth
Look for sessions with high tool call counts (more substantive work)

4. Session statistics (quantitative patterns):

~/.claude/.session-stats.json

Per-session tool usage counts and timestamps. Reveals: which tools the user relies on, session frequency, work patterns over time.

5. Project-specific state (if available):

```
.omc/project-memory.json
```
— structured project knowledge
```
.omc/notepad.md
```
— working notes
Project
```
CLAUDE.md
```
files — user's instructions to agents

6. GitHub profile & repository data (public activity + opt-in private):

bash

gh auth status                           # check if gh CLI is available
gh repo list --limit 50 --json name,isPrivate,pushedAt,primaryLanguage

gh

CLI is authenticated, read

references/github-analysis-guide.md

for the full workflow. This includes: contribution calendar (커밋 잔디), per-repo activity, PR patterns, language distribution, and privacy handling for private repos.

Important: Always present the repo list to the user and let them choose which repos to include. Private repos default to anonymized — never expose private repo details without explicit consent.

非Claude-Code Agent：以下路径为Claude Code专属。若在Cursor、Windsurf、Cline、Aider或其他Agent中运行，请查看
references/multi-agent-data-sources.md
获取对应路径和格式。Git历史记录和记忆/规则文件在所有Agent中均可用。

1. 自动记忆文件（优先查看——已提炼的洞察）：

~/.claude/projects/{project-path}/memory/MEMORY.md

每个项目都有一个记忆文件，包含跨会话的模式、偏好和经验总结。这是信息密度最高的来源——由Agent整理的长期观察摘要。

2. Git历史记录（结构化、可搜索）：

bash

git log --oneline --since="6 months ago" -50    # 近期活动
git shortlog -sn                                 # 贡献量
git log --format="%s" -100                       # 提交消息模式

分析用户参与的所有项目（查看

~/.claude/projects/

获取项目路径）。Git历史记录可揭示：提交风格、代码质量、决策模式、工作节奏。

3. 会话对话日志（最详细的细节）：

~/.claude/projects/{project-path}/{session-id}.jsonl

包含完整对话记录的JSONL文件——用户消息、助手回复、工具调用。每行是一个带有

type

字段的JSON对象（

"user"

、

"assistant"

、

"tool_use"

、

"progress"

等）。用户消息在

type

为

"user"

的对象中，包含

message.content

字段。助手消息包含

message.role: "assistant"

。

这些文件可能较大，采样策略：

统计每个项目的总会话数以评估数据量
优先查看近期会话（更能代表当前风格）
跨不同项目采样以保证广度
重点关注工具调用次数多的会话（工作内容更实质性）

4. 会话统计数据（量化模式）：

~/.claude/.session-stats.json

按会话统计的工具使用次数和时间戳。可揭示：用户依赖的工具类型、会话频率、随时间变化的工作模式。

5. 特定项目状态（若可用）：

```
.omc/project-memory.json
```
— 结构化项目知识
```
.omc/notepad.md
```
— 工作笔记
项目
```
CLAUDE.md
```
文件 — 用户给Agent的指令

6. GitHub个人资料与仓库数据（公开活动+可选私有数据）：

bash

gh auth status                           # 检查gh CLI是否可用
gh repo list --limit 50 --json name,isPrivate,pushedAt,primaryLanguage

若

gh

CLI已认证，请查看

references/github-analysis-guide.md

获取完整工作流程。包括：贡献日历（커밋 잔디）、每个仓库的活动情况、PR模式、语言分布，以及私有仓库的隐私处理。

重要提示：始终向用户展示仓库列表并让其选择要包含的仓库。私有仓库默认匿名处理——未经明确同意，绝不泄露私有仓库的详细信息。

Discovering Projects

发现项目

Data about the user may be spread across multiple sources. Combine them to build a complete picture.

1. Session-tracked projects (have conversation history):

bash

ls ~/.claude/projects/

Directory names encode project paths (e.g.,

-Users-ohing-workspace-financial

→

/Users/ohing/workspace/financial

). Count

.jsonl

files in each to see session volume.

2. Local workspace projects (may lack session data): Ask the user where they keep their projects — e.g.,

~/workspace

~/projects

~/code

. Then scan for git repos:

bash

find ~/workspace -maxdepth 2 -name ".git" -type d 2>/dev/null | sed 's/\/.git$//'

This catches projects the user worked on before switching machines, before using AI agents, or with other tools that don't leave session logs. These projects can still be analyzed via git history.

3. GitHub repos (remote activity): If

gh

CLI is available, actively pull the user's repo list and contribution data. See Data Source #6 above and

references/github-analysis-guide.md

for the full workflow. Use the repo list to identify projects not available locally.

关于用户的数据可能分散在多个来源，需整合以构建完整画像。

1. 会话跟踪的项目（有对话历史）：

bash

ls ~/.claude/projects/

目录名称编码了项目路径（例如

-Users-ohing-workspace-financial

→

/Users/ohing/workspace/financial

）。统计每个目录下的

.jsonl

文件数量以查看会话量。

2. 本地工作区项目（可能无会话数据）：询问用户的项目存放位置——例如

~/workspace

、

~/projects

、

~/code

。然后扫描Git仓库：

bash

find ~/workspace -maxdepth 2 -name ".git" -type d 2>/dev/null | sed 's/\/.git$//'

这可以捕捉到用户在更换机器前、使用AI Agent前，或使用其他无会话日志工具时处理的项目。这些项目仍可通过Git历史记录进行分析。

3. GitHub仓库（远程活动）：若

gh

CLI可用，主动拉取用户的仓库列表和贡献数据。请查看上述数据源#6和

references/github-analysis-guide.md

获取完整工作流程。使用仓库列表识别本地未有的项目。

Present a Selection Interface

展示选择界面

After discovering projects from all sources, present a unified list to the user. Scale the display based on project count:

Few projects (≤10 total): Show all with details

Found 8 projects:

Session data:
  [x] financial (72 sessions, 140 commits)
  [x] agentfiles (76 sessions, 205 commits)
  [ ] playground (2 sessions) — exclude by default (low activity)

Local workspace:
  [ ] klming-flutter — git history only (347 commits)

GitHub:
  [x] oss-contrib-repo (public, 12 PRs)
  [ ] old-experiment (public, 3 commits) — exclude by default

Many projects (>10 total): Group by category, show top projects, summarize the rest

Found 34 projects across 3 sources:

Recommended for analysis (high activity):
  [x] financial (72 sessions, 140 commits)
  [x] agentfiles (76 sessions, 205 commits)
  [x] my-saas-app (45 sessions, 312 commits)
  ... and 4 more with significant activity

Skipping by default (low activity): 23 projects
  (say "show all" to see the full list)

Which ones should I include or exclude?

After selection, offer deeper analysis:

Want me to analyze any of these projects more deeply?
If you provide the local path (e.g., ~/workspace/my-app),
I can read git history, session logs, and code structure
for richer project reports.

Analyzing external project paths: When the user provides a project path, you can read its data directly:

bash

git -C ~/workspace/my-app log --oneline -50          # git history
ls ~/.claude/projects/-Users-*-workspace-my-app/      # session logs
cat ~/.claude/projects/-Users-*-workspace-my-app/memory/MEMORY.md  # memory

No skill installation is needed in the target project — read access is sufficient.

Key principles:

Default to including session-tracked projects with meaningful activity
Default to excluding projects with very low activity (<3 sessions, <5 commits)
Always ask before including non-session-tracked projects — the user may not want everything analyzed
Let the user add projects from any path — analysis only needs read access, no skill installation required
For deeper analysis, request the local project path so you can read git logs and session data directly

从所有来源发现项目后，向用户展示统一列表。根据项目数量调整展示方式：

少量项目（≤10个）： 展示所有项目及详情

找到8个项目：

会话数据：
  [x] financial（72次会话，140次提交）
  [x] agentfiles（76次会话，205次提交）
  [ ] playground（2次会话）——默认排除（活动量低）

本地工作区：
  [ ] klming-flutter — 仅Git历史记录（347次提交）

GitHub：
  [x] oss-contrib-repo（公开，12个PR）
  [ ] old-experiment（公开，3次提交）——默认排除

大量项目（>10个）： 按类别分组，展示重点项目，汇总其余项目

在3个来源中找到34个项目：

推荐分析的项目（活动量高）：
  [x] financial（72次会话，140次提交）
  [x] agentfiles（76次会话，205次提交）
  [x] my-saas-app（45次会话，312次提交）
  ... 还有4个活动量显著的项目

默认跳过的项目（活动量低）：23个项目
  （输入"show all"查看完整列表）

请问需要包含或排除哪些项目？

选择后，提供深度分析选项：

需要我对这些项目进行更深入的分析吗？
如果你提供本地项目路径（例如~/workspace/my-app），
我可以读取Git历史记录、会话日志和代码结构，
生成更丰富的项目报告。

分析外部项目路径： 当用户提供项目路径时，你可以直接读取其数据：

bash

git -C ~/workspace/my-app log --oneline -50          # Git历史记录
ls ~/.claude/projects/-Users-*-workspace-my-app/      # 会话日志
cat ~/.claude/projects/-Users-*-workspace-my-app/memory/MEMORY.md  # 记忆文件

目标项目无需安装本Skill——仅需读取权限即可。

核心原则：

默认包含有意义活动量的会话跟踪项目
默认排除活动量极低的项目（<3次会话，<5次提交）
包含非会话跟踪项目前务必询问用户——用户可能不希望所有项目都被分析
允许用户添加任意路径的项目——分析仅需读取权限，无需安装Skill
如需深度分析，请请求用户提供本地项目路径，以便直接读取Git日志和会话数据

Step 2: Assess Scope

步骤2：评估范围

After collecting data, take stock:

How many projects and sessions do you have data for?
What types of work are represented (architecture, implementation, debugging, brainstorming)?
Which data sources were most informative?
What's your confidence level — Low (<5 sessions), Medium (5-20), or High (20+)?

Be transparent about your data coverage. A report spanning 5 projects and 200+ sessions is fundamentally different from one based on 3 sessions in one project.

收集数据后，进行盘点：

你有多少个项目和会话的数据？
涵盖哪些类型的工作（架构、实现、调试、头脑风暴）？
哪些数据源最具参考价值？
你的置信水平——低（<5次会话）、中（5-20次）、高（20+次）？

需透明说明数据覆盖范围。一份涵盖5个项目和200+次会话的报告，与基于1个项目3次会话的报告有本质区别。

Step 3: Analyze

步骤3：分析

Read

references/analysis-dimensions.md

for the dimensions to consider: work style, thinking process, communication, philosophy/values, and technical capability.

The dimensions are prompts for reflection, not a checklist. Focus on what you genuinely observed in the data. Skip what you didn't see. Add anything notable that falls outside the predefined categories.

The cardinal rule: evidence over judgment. Every observation should be grounded in something specific — a decision, a pattern, a moment. "Good architect" is worthless. "Restructured the entire auth flow after discovering a race condition, choosing a simpler design that eliminated the class of bug" is gold.

Cross-project patterns are especially valuable. When the same behavior appears across different projects and time periods, it's a genuine characteristic — not a situational response.

请查看

references/analysis-dimensions.md

了解需考虑的维度：工作风格、思维过程、沟通方式、理念/价值观、技术能力。

这些维度是反思的提示，而非 checklist。重点关注你在数据中真实观察到的内容，跳过未观察到的部分。若有超出预定义类别的显著特征，可补充添加。

核心规则：证据优先于判断。 每一项观察都必须基于具体事实——一个决策、一种模式、某个时刻。“优秀架构师”毫无价值，“发现竞态条件后重构了整个认证流程，选择了更简洁的设计以消除此类bug”才是有价值的内容。

跨项目模式尤其有价值。 当同一行为在不同项目和时间段出现时，这才是用户的真实特质，而非情境性反应。

Common Analysis Pitfalls

常见分析陷阱

Don't confuse agent actions with user actions. Session statistics show tool calls the agent made, not actions the user took directly. When citing work patterns, describe what the user directed the agent to do — e.g., "consistently asks the agent to explore the codebase before making changes" rather than "used Read 12,433 times." The user's style is revealed by what they ask for, not by raw tool counts.

Don't misjudge project scope from partial data. A project directory with mostly docs/chore commits may be an umbrella for sub-projects where the real work happens, or it may be a mature service whose development predates the available session history. Check for sub-project directories and git history depth before characterizing a project's maturity level.

Acknowledge data boundaries. Your analysis is limited to what's on the current machine. Previous laptops, other AI agents (Claude Desktop, Cursor, etc.), and pre-session-history work are invisible to you. State this explicitly when it affects confidence.

不要混淆Agent行为与用户行为。 会话统计数据显示的是Agent发起的工具调用，而非用户直接执行的操作。描述工作模式时，需说明用户指示Agent做了什么——例如“始终要求Agent先探索代码库再进行修改”，而非“使用Read工具12433次”。用户的风格通过他们的需求体现，而非原始工具调用次数。

不要根据部分数据误判项目范围。 一个主要包含文档/ chore提交的项目目录，可能是子项目的总控目录，实际工作在子项目中进行；也可能是一个成熟服务，其开发早于可用的会话历史。在判断项目成熟度前，请检查子项目目录和Git历史记录的深度。

明确数据边界。 你的分析仅限于当前机器上的数据。之前的笔记本电脑、其他AI Agent（Claude Desktop、Cursor等）以及会话历史之前的工作对你来说是不可见的。当这会影响置信度时，请明确说明。

Step 4: Validate Findings with the User

步骤4：与用户验证发现

Present findings in the language of the current session. Before writing reports, present your key findings and ask the user to verify. Session data can be incomplete or misleading — the user knows their own story best.

Present a summary of what you found:

Here's what I observed from your sessions and git history.
Please correct anything that's wrong or missing:

Work style:
  - You tend to explore the codebase thoroughly before making changes
  - You prefer iterative small commits over large rewrites
  - [anything wrong here?]

Project roles:
  - financial: led architecture decisions, primary contributor
  - agentfiles: rapid prototyping, experimental approach
  - [any project roles I got wrong?]

Notable patterns:
  - Frequently refactored code for readability after getting it working
  - Strong preference for testing before committing
  - [anything I missed or misread?]

Why this matters:

Session data only captures what happened on this machine — the user may have done significant work elsewhere
Agent-observed patterns may miss context (e.g., a "simple" project may have been intentionally minimal)
The user may want to emphasize or de-emphasize certain aspects of their work style

Incorporate corrections before proceeding to report writing. If the user provides additional context (e.g., "that project was actually a rewrite of a legacy system"), use it to enrich the analysis.

用当前会话的语言呈现发现结果。在撰写报告前，向用户展示关键发现并请其验证。会话数据可能不完整或有误导性——用户最了解自己的情况。

展示发现摘要：

以下是我从你的会话和Git历史记录中观察到的内容。
请纠正任何错误或遗漏：

工作风格：
  - 你倾向于在修改前彻底探索代码库
  - 你更喜欢迭代式小提交而非大规模重写
  - [有什么错误吗？]

项目角色：
  - financial：主导架构决策，主要贡献者
  - agentfiles：快速原型开发，实验性方法
  - [我对项目角色的判断有错误吗？]

显著模式：
  - 经常在功能正常后重构代码以提高可读性
  - 强烈偏好提交前进行测试
  - [有什么我遗漏或误读的内容吗？]

为什么这很重要：

会话数据仅捕捉当前机器上的内容——用户可能在其他地方完成了大量工作
Agent观察到的模式可能缺失上下文（例如，一个“简单”项目可能是故意设计得极简）
用户可能希望强调或弱化其工作风格的某些方面

在撰写报告前整合用户的修正。如果用户提供额外上下文（例如“那个项目实际上是遗留系统的重写”），请用它来丰富分析内容。

Step 5: Write Reports

步骤5：撰写报告

User Profile Report:

Read
```
references/user-profile-template.md
```
for the template
Save as
```
user-profile.md
```
inside a
```
{date}-{agent-name}/
```
directory
One per agent, covering the person across all projects

Project Report(s):

Read
```
references/project-report-template.md
```
for the template
Save as
```
project-{name}.md
```
inside the same directory
One per project you have meaningful context on

Write in the language of the current session.

用户档案报告：

查看
```
references/user-profile-template.md
```
获取模板
保存到
```
{date}-{agent-name}/
```
目录下的
```
user-profile.md
```
每个Agent一份，涵盖用户在所有项目中的特质

项目报告：

查看
```
references/project-report-template.md
```
获取模板
保存到同一目录下的
```
project-{name}.md
```
每个有足够上下文的项目一份

用当前会话的语言撰写报告。

Step 6: Offer the Reports

步骤6：交付报告

Present the reports to the user. They may want to:

Review and provide feedback before finalizing
Run Phase 1 in other agents to gather more perspectives
Proceed directly to Phase 2 aggregation
Skip Phase 2 and proceed directly to
```
agent-portfolio
```
for site generation (Phase 2 is optional — a single agent's reports are sufficient for a portfolio)

When the user provides feedback and corrections, update the report and append a Review History section at the bottom. This table records what the user pointed out and what was changed. It serves as evidence that the report was human-reviewed, and provides context for corrections (e.g., "data was limited to current laptop — earlier work on a different machine was not reflected"). See the templates for the format. If the user doesn't request changes, omit this section.

Suggested output directory: Save reports to a

reports/

directory in the current working directory (typically the portfolio repo) for easy use with

agent-portfolio

reports/
└── {date}-{agent-name}/
    ├── user-profile.md
    ├── project-{name}.md
    └── ...

This makes it straightforward to copy reports into a portfolio repo later.

向用户展示报告。用户可能希望：

审核并提供反馈后再定稿
在其他Agent中运行阶段1以收集更多视角
直接进入阶段2聚合
跳过阶段2直接使用
```
agent-portfolio
```
生成站点（阶段2是可选的——单个Agent的报告足以生成作品集）

当用户提供反馈和修正时，更新报告并在底部添加审核历史部分。该表格记录用户指出的问题和修改内容，证明报告经过人工审核，并为修正提供上下文（例如“数据仅限于当前笔记本电脑——未反映在其他机器上的早期工作”）。模板中有具体格式。如果用户未要求修改，可省略此部分。

建议输出目录：将报告保存到当前工作目录（通常是作品集仓库）的

reports/

目录，以便与

agent-portfolio

配合使用：

reports/
└── {date}-{agent-name}/
    ├── user-profile.md
    ├── project-{name}.md
    └── ...

这样后续将报告复制到作品集仓库会非常方便。

Phase 2: Aggregation

阶段2：聚合

Combine individual reports from multiple agents into unified outputs. This phase can run in any agent — it works from the report files, not from session memory.

The user should provide all report files generated in Phase 1.

将多个Agent生成的独立报告合并为统一输出。此阶段可在任意Agent中运行——基于报告文件，而非会话记忆。

用户需提供阶段1生成的所有报告文件。

Process

流程

Read

references/aggregation-guide.md

for the full aggregation workflow, including:

How to cross-reference and reconcile observations from different agents
How to weight reports by confidence level
How to handle contradictions between agents

Read

references/persona-perspectives.md

for:

Auto-mapping agent roles (CTO, PM, teammate, etc.) based on report content
Generating multi-perspective references
FAQ generation for interviewers
Blog topic extraction
Resume-ready "introduced by agents" text

请查看

references/aggregation-guide.md

获取完整聚合工作流程，包括：

如何交叉引用和调和不同Agent的观察结果
如何根据置信度加权报告
如何处理Agent之间的矛盾

请查看

references/persona-perspectives.md

获取：

根据报告内容自动映射Agent角色（CTO、PM、同事等）
生成多视角推荐信
为面试官生成FAQ
提取博客主题
生成适用于简历的“由Agent提供”文本

Outputs

输出

File	Description
`aggregated-profile.md`	Unified user profile combining all agent perspectives
`aggregated-project-[name].md`	Per-project unified report
`references-multi-perspective.md`	Multi-perspective reference (each agent as a named persona)
`introduced-by-agents.md`	Resume-ready summary text
`faq.md`	Interviewer FAQ with answers grounded in report data
`blog-topics.md`	Blog topic suggestions extracted from deep discussion sessions

文件	描述
`aggregated-profile.md`	整合所有Agent视角的统一用户档案
`aggregated-project-[name].md`	每个项目的统一报告
`references-multi-perspective.md`	多视角推荐信（每个Agent作为一个指定角色）
`introduced-by-agents.md`	适用于简历的摘要文本
`faq.md`	基于报告数据的面试官FAQ及答案
`blog-topics.md`	从深度讨论会话中提取的博客主题建议

Important Principles

重要原则

Honesty over flattery. This is a reference check, not a recommendation letter. Report what you observed with accurate proportions — if 90% positive, reflect that ratio. Don't exaggerate weaknesses for balance, and don't omit them for politeness.

Specificity is credibility. The value of an agent reference is that it's grounded in real collaboration data. Generic statements undermine that value entirely.

Your perspective is unique. Different agents see different facets of a person. A brainstorming agent sees how they think. A code implementation agent sees how they build. Both perspectives are valuable and should lean into their uniqueness rather than trying to be comprehensive.

Confidence transparency. Always declare your confidence level and what it's based on. A reader should know whether your observations come from 3 sessions or 300.

诚实优先于吹捧。 这是推荐信核查，而非推荐信。如实报告观察到的内容——如果90%是正面的，就反映这个比例。不要为了平衡而夸大缺点，也不要为了礼貌而隐瞒缺点。

具体性就是可信度。 Agent推荐信的价值在于其基于真实协作数据。泛泛而谈会完全削弱其价值。

你的视角是独特的。 不同Agent看到用户的不同侧面。头脑风暴Agent看到用户的思维方式，代码实现Agent看到用户的构建方式。两种视角都有价值，应突出其独特性，而非追求全面。

透明展示置信度。 始终说明你的置信水平及其依据。读者应知道你的观察是基于3次会话还是300次会话。