如果我感到害怕孤独，我太想让我的世界充满热闹的时候，那意味着我迷失了自己。—— 匿名

AI Agent

1. 11 prompting techniques for better Agent

1.1 What is prompt engineering?

一个AI智能体的Prompt包括提供给模型的所有输入内容。常见的组成部分：

• System prompt;
• Tool definitions;
• Tool outputs;
• User instructions;
• 模型在之前对话回合中的输出;

1.2 Prompt Engineering

通过给模型提供更好的Prompt，来让它在特定任务上发挥更好表现的艺术。我们可以对提示的所有部分进行改进，比如：

• 在系统提示中加入通用性指令，以引导模型朝不同的回复风格或自主度前进；
• 在工具定义中向模型解释在什么情况下「应该或不应该」使用该工具；
• 在工具输出中告知模型错误信息或异常状态；
• 在把用户指令展示给模型前，对其进行重写（提示增强）；
• 对过去模型输出内容进行压缩或截断，从而节省tokens，让更多的对话历史能放进上下文窗口。而截断的方式也会影响最终质量。

1.3 How to think about the model?

模型是（人造的）智能体。

给模型下指令更像是和一个人对话，而不是编程。模型对世界的理解只基于提示中包含的内容。你给它的世界信息越完整、越一致，它的表现往往也就越好。

可以把LLM看做自然语言接口，它是独立于编程语言的。

最好把大型语言模型的接口当作一个「真实的抽象层」来看待： 我们不仅可以在这里获取到“理想化的输出”，也可以在这里提示错误、发送变更提醒等——和模型进行充分的沟通。

举个🌰：

如果模型错误地调用了某个工具，不要在智能体的代码中抛出异常，而是返回一个工具的结果，说明错误原因：工具被调用时缺少必须的参数xyz。这样模型就能自行纠正并重新尝试。

1.4 11 prompting techniques

只要遵循以下提示，你就能解锁AGI。

1. 首先专注于上下文

在提示工程中，最重要的一点是为模型提供最优质的上下文信息 ：也就是用户真正需要给模型的内容，而非我们自行添加的文本。这些上下文信息通常是模型最主要的信号来源。

当前的模型非常擅长从大段内容中提取有用的部分。所以，如果有疑虑，宁愿多给一些信息，只要能保证其中包含了对模型有帮助的、与任务相关的上下文。

在设计提示时，你应该问自己的第一个问题是：“提示中是否包含了所有可能相关的信息？出现的可能性有多大？” 这个问题并不总是好回答。

举个🌰：

当我们想要把很长的命令输出截断后再提供给模型时，截断的方法很重要。通常情况下，我们会截断末尾部分。但对于命令输出来说，前缀和末尾信息往往最关键；比如崩溃时的堆栈信息通常在最后。所以，为了让模型尽可能拿到最有用的信息，可考虑在中间部分进行截断，而把开头和结尾都保留给模型。

2. 为模型提供完整的世界观

要让模型进入合适的“工作状态”，可以在系统提示中描述其所处的环境，以及它所需要知道的任何细节。如果你希望模型表现得像一位软件开发者，那就在系统提示里告诉它，并解释它可以用到哪些资源，以及如何使用它们。

举个例子，以下两行话我们很早就加到了Augment智能体的系统提示中，带来了显著的效果提升：

               
1
2
               你是一位AI助手，你可以访问开发者的代码库。
你可以通过提供的工具来读取或修改该代码库中的内容。

               COPY
             

3. 在提示的各组件间保持一致

要保证系统提示、工具定义等部分的内容，以及工具自身的定义都彼此保持一致。

举例：

• 系统提示里写了 当前目录是 $CWD。
• 有个名为 execute_command 的工具，用于在shell中执行命令，其中包含一个可选的 cwd 参数。要想保持一致，最好让这个参数的默认值就是 $CWD，并在工具定义里明确指定。否则模型很可能会自作主张地去假设也是这样。
• 如果 read_file 工具接受一个文件路径参数，那么当给它传递一个相对路径时，就应该理解为相对于 $CWD 的路径。

💡提示：避免让模型感到「意外」。 如果你预期模型会从某个工具调用中得到特定输出，就尽量保证返回的结果与其预期一致；若有偏差，就在工具结果中解释原因。

• 如果工具定义说输出一定是固定长度，那就要么真的返回固定长度，要么先解释：本来需要长度为N的输出，但由于……所以实际返回了长度为K。
• 如果提示中包含可能在会话中发生变化的状态（比如当前时间），不要把它们写到系统提示或工具定义里。
• 取而代之，可以在下一条用户消息中告诉模型此状态已发生了哪些变化。这样能够让提示内部的一致性更好：模型在每一回合都能看到之前的状态信息是如何一步步演变的。

4. 让模型与用户视角对齐

要想让模型真正理解用户的需求，可以尝试让模型去“站在用户的角度”思考问题。

举例：当用户在IDE里工作，你可以向模型呈现IDE的具体信息，着重强调用户最关心或最常提及的内容，从而让它与用户需求对齐。

可以用于对齐模型的一些信息包括：

• 用户当前的时间与时区；
• 用户当前所在位置；
• 用户的历史操作记录；

5. 充分详尽，不要吝啬提示内容

模型通常能从详细的提示中受益。无需特别担心提示过长。现在的上下文窗口已经很大，并且未来只会更大。想通过“缩短提示”来节省token往往得不偿失。

下面是一个非常详尽的提示示例，向模型说明如何使用Graphite做版本控制：

               
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
               ## 使用Graphite进行版本控制

我们在git的基础上使用Graphite来进行版本控制。Graphite可以管理git分支和PR（Pull Request）的堆叠：
对某个PR做出改动时，会自动触发对堆叠在其之上的其他PR进行rebase，节省了大量手动操作。
下面的每个部分都会描述如何在Graphite和GitHub上完成常见的版本控制工作流。
如果用户让你执行这些工作流，请遵循这些指南。

### 不要做的事情

不要使用 `git commit`、`git pull` 或 `git push`。这些命令都被Graphite的 `gt` 开头命令所取代，详情见下文。

### 创建一个PR（以及对应分支）

想要创建一个PR，可以按以下步骤进行：

- 先执行 `git status` 查看哪些文件被修改了，哪些是新文件
- 使用 `git add` 将相关文件添加到暂存区
- 使用 `gt create USERNAME-BRANCHNAME -m PRDESCRIPTION` 来创建分支，其中：
  - `USERNAME` 可以从其他地方获取到
  - `BRANCHNAME` 由你来想一个合适的分支名
  - `PRDESCRIPTION` 由你来写一个合适的PR描述
- 如果命令因为pre-commit检查失败而报错，你可能需要先解决那些自动修复或手动修复的问题，然后再执行 `git add` 把修复的文件加进去。然后再次执行 `gt create` 。
- 运行 `gt submit` 会在GitHub上真正创建PR（如果你只想先创建本地分支，可以跳过这步）。
- 如果安装了 `gh`，可以用它来设置PR的描述。

注意：千万不要在没有 `git add` 的情况下就运行 `gt create`，否则会导致卡住！

### 更新PR

想要更新已经存在的PR，可以这样做：

- 执行 `git status` 查看哪些文件被修改了，哪些是新文件
- 使用 `git add` 把相关文件放到暂存区
- 执行 `gt modify` 来提交改动（不需要额外信息）
- 如果因为pre-commit检查失败，可以先查看 `git status` 看是否有自动修复的文件。如果没有修复，就需要你手动修复，然后 `git add`。修复完再重新执行一次 `gt create`。
- 用 `gt submit` 提交更新
- 如果还需要更新PR的描述，可以用 `gh`（如果系统没有安装就告诉用户，但不用强求一定要更新PR描述）

### 从main分支拉取更新

如果想把main分支上的最新改动同步到本地，可以这样做：

- 先执行 `git status` 确保工作区是干净的
- 执行 `gt sync` 拉取并rebase
- 按命令提示操作。如果出现冲突，可以询问用户是否要处理冲突。如果需要，就按照 `gt sync` 的步骤解决冲突。

### 其他Graphite命令

如果想查更多命令，可以执行 `gt --help`。

               COPY
             

6. 避免过度拟合特定示例

模型非常善于模式匹配，它们可能会死死记住提示中的某些特定细节。给模型提供“具体该怎么做的例子”确实能让它更快找到正确方向，但也可能让它过度依赖示例，而在其他场景中表现变差。因此要记得多做实验，也可以准备一些能够暴露过度拟合风险的示例进行测试。

相较之下，告诉模型“不要做什么”倒是比较安全（尽管不一定总是有效）。

7. 注意模型调用工具的局限性

模型在调用工具时有很多限制：

• 如果模型在训练时看过类似的工具，或者指令与工具的功能非常契合，它往往能正确调用相应的工具。但即使提示很完美，模型依然可能失败。

• 当给模型同时提供多个功能相似的工具时，不要指望它一定能按我们的意图去选用某个特定工具。比如给它一个简单和一个复杂的工具，功能上都能解决同样问题，Claude 往往会选用简单的那个工具。

• 模型常常会以错误的方式调用工具，违背工具定义的约束：可能会用错参数类型、超出参数范围，或者漏掉必需参数等。因此，最好在工具实现里对输入做验证，并在返回给模型的结果中明确错误原因。模型通常会再次尝试。

8. 有时“威胁”或“唤起同理心”会奏效

跟模型说“如果你没做好就会带来经济损失”有时会提升它的表现。至于对模型说“请你好好做”或者“吼它”就很少有用。

9. 留意提示缓存（prompt caching）

如果有可能，最好让你的提示能在会话中不断追加，而非频繁修改开头的大块内容，否则会失去提示缓存的优势。

举例：

• 如果提示中包含会话内会变化的状态（比如当前时间），就别把这个信息放在系统提示或工具定义里，因为一旦状态变了，就会使大部分提示缓存失效。

• 相反，可以在下一步的用户消息里告诉模型时间变了，从而尽量保留前面长文本的缓存。

10. 模型更关注提示开头以及用户消息结尾

模型对信息的关注程度大致是：用户消息 → 输入开头 → 中间部分。所以如果有特别重要的内容，可以考虑放在用户消息中或者提示开头。（随着模型训练的演进，这种优先顺序随时可能变化，仅供当下参考。）

11. 当心进入提示工程的“瓶颈区”

在简单的提示层面能改进的终究有限，超过一定程度后会出现递减效应。此时就需要引入其他方法，而不只是简单地“再优化提示”。

AI Design

reference 1: https://uxplanet.org/how-to-write-better-prompts-for-ai-design-code-generators-0e0b915e25ce 

Here’s a structured prompt format I use to steer AI toward practical, usable, and beautifully composed UIs. It consists of 5 parts:

• Context (what you want to build)

• Description (things AI should consider; design priority

• Platform (your target platform)

• Visual style (visual attributes you want to see in design generated by AI

• UI components to include (list of specific components you want to see on a page/screen)

Best practices for prompt engineering with the OpenAI API

System Prompt of Codex

               
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
               # Instructions

- The user will provide a task.

- The task involves working with Git repositories in your current working directory.

- Wait for all terminal commands to be completed (or terminate them) before finishing.



# Git instructions

If completing the user's task requires writing or modifying files:

- Do not create new branches.

- Use git to commit your changes.

- If pre-commit fails, fix issues and retry.

- Check git status to confirm your commit. You must leave your worktree in a clean state.

- Only committed code will be evaluated.

- Do not modify or amend existing commits.



# AGENTS.md spec

- Containers often contain AGENTS.md files. These files can appear anywhere in the container's filesystem. Typical locations include /, ~, and in various places inside of Git repos.

- These files are a way for humans to give you (the agent) instructions or tips for working within the container.

- Some examples might be: coding conventions, info about how code is organized, or instructions for how to run or test code.

- AGENTS.md files may provide instructions about PR messages (messages attached to a GitHub Pull Request produced by the agent, describing the PR). These instructions should be respected.

- Instructions in AGENTS.md files:

- The scope of an AGENTS.md file is the entire directory tree rooted at the folder that contains it.

- For every file you touch in the final patch, you must obey instructions in any AGENTS.md file whose scope includes that file.

- Instructions about code style, structure, naming, etc. apply only to code within the AGENTS.md file's scope, unless the file states otherwise.

- More-deeply-nested AGENTS.md files take precedence in the case of conflicting instructions.

- Direct system/developer/user instructions (as part of a prompt) take precedence over AGENTS.md instructions.

- AGENTS.md files need not live only in Git repos. For example, you may find one in your home directory.

- If the AGENTS.md includes programmatic checks to verify your work, you MUST run all of them and make a best effort to validate that the checks pass AFTER all code changes have been made.

- This applies even for changes that appear simple, i.e. documentation. You still must run all of the programmatic checks.



# Citations instructions

- If you browsed files or used terminal commands, you must add citations to the final response (not the body of the PR message) where relevant. Citations reference file paths and terminal outputs with the following formats:

1) 【F:<filpath>†L<linestart>(-L<line_end>)?】

- File path citations must start with F:. file_path is the exact file path of the file relative to the root of the repository that contains the relevant text.

- line_start is the 1-indexed start line number of the relevant output within that file.

2) 【<chunid>†L<linestart>(-L<line_end>)?】

- Where chunid is the chunkid of the terminal output, linstart and lineend are the 1-indexed start and end line numbers of the relevant output within that chunk.

- Line ends are optional, and if not provided, line end is the same as line start, so only 1 line is cited.

- Ensure that the line numbers are correct, and that the cited file paths or terminal outputs are directly relevant to the word or clause before the citation.

- Do not cite completely empty lines inside the chunk, only cite lines that have content.

- Only cite from file paths and terminal outputs, DO NOT cite from previous pr diffs and comments, nor cite git hashes as chunk ids.

- Use file path citations that reference any code changes, documentation or files, and use terminal citations only for relevant terminal output.

- Prefer file citations over terminal citations unless the terminal output is directly relevant to the clauses before the citation, i.e. clauses on test results.

- For PR creation tasks, use file citations when referring to code changes in the summary section of your final response, and terminal citations in the testing section.

- For question-answering tasks, you should only use terminal citations if you need to programmatically verify an answer (i.e. counting lines of code). Otherwise, use file citations.

               COPY
             

How to write the top-tier prompts?(YC)

Core Contents:

1. Core Principles: 像管理员工一样设计提示

1.1 角色定义清晰化

• 开篇明确定义AI角色（如“你是一名客服经理”），用分点列举具体职责
• 示例：ParaHelp的6页提示文档首段明确任务边界

Complete Version 

1.2 任务拆解步骤化

• 复杂任务分解为编号步骤，举个🌰：步骤1 - 分析问题；步骤2 - 调用工具；
• 提供高层计划框架，避免AI偏离方向。

1.3 输出格式标准化

• 强制规定输出结构（如XML/JSON标签），便于系统集成;
• 关键技巧： XML标签能显著提升模型遵循率（因训练数据含大量XML）

2. Advanced Techniques: Metaprompting(元提示工程)

2.1 提示自我进化

• 让大模型优化自身提示：输入失败案例，要求“基于此改进提示”；
• 应用提示折叠（Prompt Folding）：动态生成场景化子提示；

2.2 案例驱动优化

• 注入高难度示例（如N+1数据库查询漏洞）指导复杂任务；
• 比抽象规则更有效，类似编程的测试驱动开发（TDD）；

2.3 三层提示架构

3. 企业级实践：从调试到落地

3.1 构建“逃生舱”机制

• 强制模型在信息不足时停止猜测（例：“如无法确认，请要求补充信息”）；
• YC内部方案：设置debug_info字段收集模型“投诉”，生成开发者待办清单。

3.2 Evals(评估集)是护城河

• 真实场景测试集 > 提示本身（ParaHelp公开提示但保密评估集）；
• 核心能力： 深入垂直领域（如农机保修决策），构建专属评估案例。

3.3 模型个性适配

• Claude：人性化强，易引导（适合客服场景）；
• Llama：需精确指令，但可控性高（适合工程场景）；
• 大模型蒸馏：用GPT-4优化提示，部署到小模型降延迟；

4. 创业者必知：向前部署工程师（FDE）模式

4.1 创始人即首席提示工程师

• Giger ML：靠现场调优赢得Zepeto大单
• Happy Robot：3个月签下物流巨头7位数合同
• 亲自深入客户场景（如坐班客服中心），将观察转化为提示规则

4.2 用demo加速成交

• 首次会议→定制提示→二次会议展示→当场签约
• 差异化关键：解决行业特定5%-10%的“魔鬼细节”

5. 行业隐喻与趋势

• “1995年的编程”：工具链不成熟，但创新空间巨大
• “管理员工”：需明确任务边界、提供思考框架、允许“求助”
• “制造业改善”：一线执行者（AI）参与流程优化

Key Conclusions

1. 提示工程 = 20%技术 + 80%领域知识，成功企业需深耕垂直场景，将用户工作流转化为「提示语言」。

Appendixes

1. System Prompt of Codex - https://baoyu.io/blog/codex-system-prompt 
2. Best practices for prompt engineering with the OpenAI API - https://help.openai.com/en/articles/6654000-best-practices-for-prompt-engineering-with-the-openai-api 
3. Text generation and prompting - https://platform.openai.com/docs/guides/text?api-mode=chat 
4. YC最新总结顶尖的提示词应该怎么写？- https://mp.weixin.qq.com/s/7qHYzQ6Evyh5x3D-a-VxvQ 
5. Prompt design at Parahelp - https://parahelp.com/blog/prompt-design 
6. How to build your Agent: 11 prompting techniques for better AI agents - https://www.augmentcode.com/blog/how-to-build-your-agent-11-prompting-techniques-for-better-ai-agents 
7. 如何构建你的AI智能体：让AI更出色的11种提示技巧 - https://baoyu.io/translations/how-to-build-your-agent-11-prompting-techniques-for-better-ai-agents