文科生如何用 AI 做出第一个真实项目
从一个能验收的小问题开始：如何向 AI 说明需求、准备样例、检查结果，以及判断一个项目是否真的可用。
FIELD NOTES / AI 实践指南
文科生的 AI 实践
把一个想法做出来，需要说清问题，也需要检查结果。从小项目、开源协作到 Agent 任务管理，按眼前的问题选择一篇开始。
从想法到项目
给 AI 的任务说明怎么写：一份可以直接填写的模板
让 AI 做项目时，最容易漏掉的往往是完成条件。说“做一个报名页面”，它可能交出界面，也可能接上数据库；双方对“完成”的理解不同，后面的修改就会不断扩大范围。
怎样把“这个不太对”变成 AI 能执行的修改意见
发现结果不对，已经完成了一半判断。接下来要说明的是：在哪里不对，为什么影响使用，希望看到什么变化。
AI 项目怎样缩小第一轮实验
有一个很大的产品想法时，可以先找出它最依赖、又最不确定的假设。第一轮实验只负责验证这个假设，结果会决定下一步该继续做什么。
Agent 协作与验收
使用 OpenClaw 和 AI Agent：怎样设置任务、权限与验收
把一个模糊目标拆成可验收任务，分别约定执行范围、对外操作和停止条件，减少多人或多 Agent 协作中的重复与失控。
Agent 说“完成了”之后，怎样验收结果
一份交付报告可以说明 Agent 做了什么，但最终验收还需要检查结果。测试通过、文件生成、网页上线，分别证明不同的事情，不能相互替代。
一个 Agent 还是多个 Agent：从任务结构决定分工
任务复杂，不一定意味着需要更多 Agent。关键在于工作能否拆成相对独立、可以分别检查的部分，以及合并结果需要花多少精力。
怎样给长期工作的 Agent 写岗位说明
一次性任务结束后可以关闭；长期 Agent 则会持续遇到新材料、新情况和旧规则失效的问题。岗位说明需要告诉它平时做什么，也要说明何时不该继续。
怎样给 Agent 工作流安排独立复核
让 Agent 自己检查结果有帮助，但执行和验收如果使用相同的错误前提，复核仍可能漏掉问题。独立复核的关键，是用明确标准检查产物，并保留能够追溯的依据。
GitHub 开源协作
不懂代码，如何用 AI 参与 GitHub 开源项目
理解 Issue、Fork、分支和 PR，从复现一个小问题开始，完成修改、验证与清楚的提交说明。
用 AI 整理 GitHub Issue：让维护者能够复现问题
一个有帮助的 Issue，让维护者看得懂问题，也能用合理的成本检查问题。AI 可以整理文字和提取步骤，但观察事实仍要来自实际发生的行为。
AI 改完代码后，怎样写清楚一份 PR
PR 是请求项目合并修改的入口。GitHub 的说明将它用于提出、讨论和审查变更；创建 PR 不意味着维护者已经接受修改。[GitHub 官方说明](https://docs.github.com/en/pull-requests/reference/pull-requests)
产品与工作系统
ClawNative 是什么：从 Agent 使用产品的过程理解
ClawNative 在杨天润的产品讨论中，指从设计起点就考虑 Agent 如何发现、理解和使用产品。它是一种产品主张，并非行业认证，也不是一个统一的技术标准。
换一个 AI 工具，怎样保留原来的工作方法
迁移 AI 工具之前，先找出工作中哪些信息只存在于旧聊天里。目标、最终决定、输出格式和错误案例，如果没有单独保存，新工具就需要重新猜测。
管理者怎样把一次进度汇总交给 AI
想在团队里引入 AI，可以先选择一项重复、容易检查的工作，例如汇总项目进度。目标是减少转述时间，同时让遗漏和异常更容易被看见。
更完整的个人思考与经历，收录在文章索引中。