生成式软件工程
搜索
开始阅读/收尾/做出一个作品

做出一个作品

读完讲义不等于学会。检验标准只有一个:有没有一个你自己每天愿意打开的东西。

这一页讲什么
  • 为什么以「能帮上自己」作为起点,而不追求像某个产品;
  • 两个项目方向的具体要求与边界;
  • 从零到第一版该按什么顺序走;
  • 怎么判断自己搭的这套做法真的有用。

一、起点选「能帮上自己」

新手做项目最常见的失败方式,是选一个听起来很酷的目标:一个社交平台、一个电商网站、一个能替代某知名工具的应用。 这类目标的问题在于,你没有真实用户,也就没有真实的反馈,做完之后无法判断它好不好。

更可靠的做法是找一个你自己每天都会遇到的小麻烦:课程表总要看三遍、每周要汇总一次报名表、 通知里的截止时间总要翻聊天记录找、照片越存越乱。这些麻烦有三个好处:你知道痛在哪、你能判断做得好不好、 做出来你明天就会用。

生活类比 做项目像练投篮。站在三分线外投一百个不进,不如站在罚球线上投进五十个。 后者让你知道手感和动作对不对,前者只让你累。选一个能立刻验证的小目标,练习效果差得很远。

二、方向一:会成长的个人助手

做一个持续为你工作的助手。它的核心是能被你纠正,并把纠正记住,功能数量并不重要。

五项基础能力

  1. 个人资料库:能索引、检索你自己的资料,资料变化后索引能更新,回答时能指明出自哪份原文。推荐用 Markdown 加目录结构,你能直接打开看它读了什么、写了什么。
  2. 接一个真实的邮箱或消息源:能持续拿到新消息,结合历史往来拟草稿。草稿由你编辑确认后再发出,发出的必须是你确认的版本。重复检查不能重复处理或重复发送同一封。
  3. 办一件真实的线上事务:在某个真正在用的系统里查询信息并完成至少一种事务的材料准备与表单填写。行为要保守:提交前展示关键字段与后果,由你明确确认。
  4. 手机端联动:能从手机发起任务、查看进度、确认操作。不能依赖桌面上某个一直开着的对话窗口。
  5. 能力组合:以上功能共享必要的上下文,完成一条跨工具的完整流程。
必须坚持的边界 涉及真实系统的操作要逐条写清「哪些步骤允许自动、哪些必须等你确认」。退课、撤销申请、付款、发邮件这类不可逆动作, 助手不能自行决定。一个能替你退掉全部课程的助手,功能再强也不能用。

怎么让它「成长」

成长指的是:你纠正过一次的错误,下次不再犯。实现方式是把你纠正的内容写成三样东西之一—— 一条写进项目规则文件里的约定、一个脚本、一份技能文件。例如你指出「不要把报名截止时间当成活动开始时间」, 这条规则要能在下一个全新的会话里被读取并生效。

把实现与规则都用版本管理起来。每次它做对了一件复杂的事,把那条流程固化下来,下次直接调用。 这个过程本身就是在积累你自己的方法论。

三、方向二:用更多计算换更好的结果

做一个带「投入档位」开关的求解流程。低档位直接给答案,高档位多花时间探索与查证,最后比较两者质量。

把解题看成搜索

有经验的人解题时会先广泛试几个方向,挑有希望的深入。多数助手拿到任务后会沿着第一个想到的路一直走, 方向对了很快,方向错了会浪费大量时间。你可以把这个过程显式化:

flowchart TB
  A["任务"] --> B["第一步尝试
得到一份答案"] B --> C["检查与评估
找出可疑的地方"] C --> D["注入新的引导
换方向或补证据"] D --> E["再求解
得到新答案"] E --> C C -->|"预算用完或已达标"| F["输出当前最好的答案"]

每一轮都用一句话引导它换个角度,例如「找出这份结论中最可疑的一步」「去找支持相反结论的材料」 「先构造一个最简单的反例」。这些问题不是随便挑的,值得从你读过的论文里提炼:作者在验证自己的猜想时用了什么办法。

实现要点

四、从哪里开始:五步路线

  1. 写下一句话目标:谁在什么场景下用它解决什么问题。写不出这句话,说明目标还没想清楚。
  2. 划出第一版的边界:只做一条完整流程,其余全部砍掉。第一版的目标是能用一次,不是功能齐全。
  3. 写下验收标准:什么现象出现就算做成了,什么现象出现说明想错了。两条都要写。
  4. 让它跑起来:先做出能观察的东西,观察之后再改。纸面上想得再清楚,第一次运行总会暴露没预料到的问题。
  5. 用一次,记录三行:哪里省了时间、哪里猜错了、下次补哪条规则。这个记录是下一轮改进的唯一依据。
关键结论 第一版粗糙是正常的,做不出来才是不正常的。判断第一版是否合格的标准很朴素:你会不会明天再用一次。 会,就继续加;不会,就换目标。这比任何功能清单都准。

五、怎么判断自己搭的这套做法真的有用

很容易发生这种事:兴冲冲搭了一套框架,花了很多时间与费用,效果却不如直接让助手做一次。 所以必须对比,而且要在动手前就定好怎么比。

最小可行的对比办法

  1. 选三到五个你真实会用的任务,把输入资料固定下来。
  2. 跑三种条件:直接做一次、低档位、高档位。
  3. 记录四项:结果质量、耗时、消耗、你自己的满意度。
  4. 先定评价标准再跑:例如事实与引用是否准确、要求是否都完成、代码是否通过测试。看到结果之后再挑标准,等于自己骗自己。

对于报告这类没有标准答案的任务,可以把三份结果的标签隐藏、顺序打乱,请另一个人或另一个助手比较, 并要求它指出具体依据。评价也可能出错,关键结论仍要自己核查。

更严格的做法院叫消融实验:把框架拆开,逐项去掉一个设计,看结果是否真的变差。这需要更多时间与费用, 但对判断「这套设计里哪一部分真正起作用」最有效。

现在就做 ① 写下三个你本周重复做过三次以上的小麻烦。
② 从中挑一个,用一句话写清「谁在什么场景下用它解决什么问题」。
③ 写下第一版的验收标准:出现什么现象算做成,出现什么现象说明想错了。
④ 把这三行贴进一个新建的 README.md,用版本管理提交一次。
做完这四步,项目就已经开始了。剩下的是执行。

自测

1. 为什么建议以「能帮上自己」作为项目起点?
因为你能判断做得好不好、明天会不会用、哪里还差。没有真实用户时,做出来的东西无法评估,容易在错误方向上越走越远。真实的小麻烦提供了免费且高频的反馈。
2. 「会成长」具体指什么?
指你纠正过一次的错误下次不再犯。实现方式是把纠正沉淀成项目规则、脚本或技能文件,让下一次全新的会话能读到并生效。只把纠正留在当次对话里,等于没有成长。
3. 为什么要在动手前定好评价标准?
看到结果之后再挑标准,会本能地挑对自己有利的指标,得出的结论没有意义。先定标准,才能诚实地判断这次改动是进步还是退步。
4. 搭好的框架效果不如直接问一次,怎么办?
先确认数据是否真实:固定输入、跑够次数、标准是否提前定好。如果确实不如,就砍掉没有贡献的部分。框架的价值在于它解决的麻烦是否真实存在,不存在的麻烦不值得为它付复杂度。