做出一个作品
读完讲义不等于学会。检验标准只有一个:有没有一个你自己每天愿意打开的东西。
- 为什么以「能帮上自己」作为起点,而不追求像某个产品;
- 两个项目方向的具体要求与边界;
- 从零到第一版该按什么顺序走;
- 怎么判断自己搭的这套做法真的有用。
一、起点选「能帮上自己」
新手做项目最常见的失败方式,是选一个听起来很酷的目标:一个社交平台、一个电商网站、一个能替代某知名工具的应用。 这类目标的问题在于,你没有真实用户,也就没有真实的反馈,做完之后无法判断它好不好。
更可靠的做法是找一个你自己每天都会遇到的小麻烦:课程表总要看三遍、每周要汇总一次报名表、 通知里的截止时间总要翻聊天记录找、照片越存越乱。这些麻烦有三个好处:你知道痛在哪、你能判断做得好不好、 做出来你明天就会用。
二、方向一:会成长的个人助手
做一个持续为你工作的助手。它的核心是能被你纠正,并把纠正记住,功能数量并不重要。
五项基础能力
- 个人资料库:能索引、检索你自己的资料,资料变化后索引能更新,回答时能指明出自哪份原文。推荐用 Markdown 加目录结构,你能直接打开看它读了什么、写了什么。
- 接一个真实的邮箱或消息源:能持续拿到新消息,结合历史往来拟草稿。草稿由你编辑确认后再发出,发出的必须是你确认的版本。重复检查不能重复处理或重复发送同一封。
- 办一件真实的线上事务:在某个真正在用的系统里查询信息并完成至少一种事务的材料准备与表单填写。行为要保守:提交前展示关键字段与后果,由你明确确认。
- 手机端联动:能从手机发起任务、查看进度、确认操作。不能依赖桌面上某个一直开着的对话窗口。
- 能力组合:以上功能共享必要的上下文,完成一条跨工具的完整流程。
怎么让它「成长」
成长指的是:你纠正过一次的错误,下次不再犯。实现方式是把你纠正的内容写成三样东西之一—— 一条写进项目规则文件里的约定、一个脚本、一份技能文件。例如你指出「不要把报名截止时间当成活动开始时间」, 这条规则要能在下一个全新的会话里被读取并生效。
把实现与规则都用版本管理起来。每次它做对了一件复杂的事,把那条流程固化下来,下次直接调用。 这个过程本身就是在积累你自己的方法论。
三、方向二:用更多计算换更好的结果
做一个带「投入档位」开关的求解流程。低档位直接给答案,高档位多花时间探索与查证,最后比较两者质量。
把解题看成搜索
有经验的人解题时会先广泛试几个方向,挑有希望的深入。多数助手拿到任务后会沿着第一个想到的路一直走, 方向对了很快,方向错了会浪费大量时间。你可以把这个过程显式化:
flowchart TB A["任务"] --> B["第一步尝试
得到一份答案"] B --> C["检查与评估
找出可疑的地方"] C --> D["注入新的引导
换方向或补证据"] D --> E["再求解
得到新答案"] E --> C C -->|"预算用完或已达标"| F["输出当前最好的答案"]
每一轮都用一句话引导它换个角度,例如「找出这份结论中最可疑的一步」「去找支持相反结论的材料」 「先构造一个最简单的反例」。这些问题不是随便挑的,值得从你读过的论文里提炼:作者在验证自己的猜想时用了什么办法。
实现要点
- 保存工作区:资料来源、当前答案、评审意见、历史较优版本都存在一个目录里,每一轮读写这个目录。
- 档位控制预算:低档位跑一轮,中档位跑三轮并检查关键结论,高档位跑更多轮并强制补充证据。预算可以是轮数,也可以折算成费用。
- 保留最好的版本:新一轮没有变好,就退回上一轮的结果。不要在越改越差时还继续往下走。
- 把发现写成规则:某一类引导反复有效,就把它固化进流程,下次自动带上。
四、从哪里开始:五步路线
- 写下一句话目标:谁在什么场景下用它解决什么问题。写不出这句话,说明目标还没想清楚。
- 划出第一版的边界:只做一条完整流程,其余全部砍掉。第一版的目标是能用一次,不是功能齐全。
- 写下验收标准:什么现象出现就算做成了,什么现象出现说明想错了。两条都要写。
- 让它跑起来:先做出能观察的东西,观察之后再改。纸面上想得再清楚,第一次运行总会暴露没预料到的问题。
- 用一次,记录三行:哪里省了时间、哪里猜错了、下次补哪条规则。这个记录是下一轮改进的唯一依据。
五、怎么判断自己搭的这套做法真的有用
很容易发生这种事:兴冲冲搭了一套框架,花了很多时间与费用,效果却不如直接让助手做一次。 所以必须对比,而且要在动手前就定好怎么比。
最小可行的对比办法
- 选三到五个你真实会用的任务,把输入资料固定下来。
- 跑三种条件:直接做一次、低档位、高档位。
- 记录四项:结果质量、耗时、消耗、你自己的满意度。
- 先定评价标准再跑:例如事实与引用是否准确、要求是否都完成、代码是否通过测试。看到结果之后再挑标准,等于自己骗自己。
对于报告这类没有标准答案的任务,可以把三份结果的标签隐藏、顺序打乱,请另一个人或另一个助手比较, 并要求它指出具体依据。评价也可能出错,关键结论仍要自己核查。
更严格的做法院叫消融实验:把框架拆开,逐项去掉一个设计,看结果是否真的变差。这需要更多时间与费用, 但对判断「这套设计里哪一部分真正起作用」最有效。
② 从中挑一个,用一句话写清「谁在什么场景下用它解决什么问题」。
③ 写下第一版的验收标准:出现什么现象算做成,出现什么现象说明想错了。
④ 把这三行贴进一个新建的
README.md,用版本管理提交一次。做完这四步,项目就已经开始了。剩下的是执行。