注：由于甲方在合同中增加了知识产权的相关条款，本文中不涉及任何细节技术问题和项目的实现逻辑。

一、项目从哪里来

这个客户是朋友的朋友，在一次牌局上认识的，下文中我们叫他宇哥。闲谈中宇哥了解到我懂一些计算机的相关内容，便说自己是开装修公司的，一直想找人做一个装修报价的小程序，但都因为对方报价过高作罢。宇哥问我认不认识有能力承接这个项目的朋友（或者我自己），可以介绍给他认识认识。

我是物理出身，虽然在跨考计算机的时候学了408，但我自认完成不了项目的完整开发，撑死算是能磕磕绊绊读懂代码（仅限C和python），因此婉拒了宇哥的邀请。

我相熟的朋友也大多还在外省读书，据我了解没有商业开发的经验。即使他们中不乏特别优秀、只要研究下肯定能完成这个项目的人，但考虑到异地的沟通成本和信任成本，我最终也没有选择给宇哥介绍。

在后续闲聊的时候，宇哥抱怨说他找的公司报价都要十万八万，在没有收到定金前也不会提供原型。我开玩笑说他被当年猪宰了，找一个熟练的程序员写这样一个小程序只需要一个月，三四万的报价会比较合适。

后续等我回家，我突然想这个我现在是不是自己也能做（准确说是自己在Claude的带领下…）。彼时我已经初步体会了Claude的强大，平时也会用Claude Code辅助写一些简单的脚本提高工作效率，但从没有完成一个完整的项目开发，还是用我从来没用过的语言。于是我决定先做一个原型，如果原型开发顺利，拿给宇哥看既能体现我的诚意，又能体现我的水平；如果不顺利，那我就当这件事从来没发生过。

一切远比我想象的顺利，既没有出现莫名其妙的报错、不知所云的代码，也没有让我的token额度如奶油般化开。 一天，刨去所有配置环境、安装开发者工具这些准备工作，Claude完成整个项目原型只用了一天。

然后就是联系宇哥，用Claude推荐的话术给他推荐Claude做的原型，拿下了这个单子。

二、需求到底是什么——比我想象的更难搞清楚

宇哥是所有乙方梦想的甲方：打钱快、要求明确。但哪怕是这样完美的甲方，最终实际要我做出的功能也和最开始描述的需求有所出入。有很多功能是聊着聊着才冒出来的——比如最开始只说要做一个报价计算器，聊到后来变成了要做后台管理系统、旧房改造计算器、微信支付，工作量翻了好几倍。

但我觉得这很正常。新需求是产品的常态，而新目标、新计划是人生的常态。随着事情的动态发展，总会有些事前没有考虑到的情况改变原有打算，适应这种变化是生活的重要部分。关键不是阻止需求变化，而是让每一次变化都被记录在纸面上、体现在价格里。

举个具体的例子。宇哥一开始给我描述的是"用户输入面积，选个档次，算出总价"，听起来很简单对吧？结果等他把四份Excel报价表发给我，我发现里面有上百个施工项目，三个装修档次用的材料和工艺完全不同，每个空间的面积计算公式也不一样。光厨房就有十几个计算项，有的按面积算、有的按根算、有的还要判断"有没有烟道口"。

再后来宇哥又发了一张CAD截图，里面画着一个"其他项目"页面，有楼层搬运费、家政费、家具搬动费、材料搬运费，每一项都有自己的触发条件和计算公式。这些东西在最初的需求里完全没提过，但确实是业务上需要的。

所以我的经验是：第一次见面时一定要录音。不是为了留证据，是因为甲方说的很多信息你当时觉得不重要、回去才发现是关键。

在完成整个开发流程的过程中，把甲方的表达转化为Claude Code可执行的开发任务也是一个重要挑战。我的经验是这样的：先把甲方的原话（录音转文字、聊天记录、他发来的图片和文件）丢给Claude，让Claude自己生成prompt，然后用Claude的prompt进行开发。我最开始也试着自己讲清楚具体的开发任务，但在无数次不理想的输出后，我认命了。Claude给出的任务描述永远比我写的更清晰、更完整、更可执行。承认自己不如AI并不丢人，善用AI才是本事。

三、报价：我是怎么定价的

考虑到之前我告诉宇哥三四万的价格比较合适，我给出的报价是全部开发3.2万，分四个阶段：

  • 第一阶段：毛坯房报价计算器 + 小程序上线，5000元
  • 第二阶段：微信支付，5000元
  • 第三阶段：后台管理系统，5000元
  • 第四阶段：旧房改造计算器，7000元

不管是合同还是款项，都是分阶段签署和结清的。每个阶段开发完成后都会验收并结款，做完一个再开下一个。这样做的好处是双方风险都很低——宇哥最多先出2500试试水，我也不用一口气承诺做完所有东西。

定价的逻辑其实很简单：我估算了每个阶段的工作量，按大约1000-1500元/天的日薪来算（这在个人接单市场里是正常偏低的水平），然后取整。宇哥还了一些价，我在工作量较低的部分作了让步，但工作量高的部分坚持了原价。

后来在实际开发中，第二阶段出现了变更——宇哥决定先不做支付，而是把旧房改造提前。这种事在项目中很常见，好在我们是分阶段签合同的，直接把第二阶段的合同内容改成旧房改造就行了，没有产生任何纠纷。如果一开始就签了一个大合同把所有功能锁死，这种灵活调整就会很麻烦。

实际工作量方面，由于每阶段开发前都会重新确认需求、签新合同，我可以根据实际的复杂度来调整报价。比如旧房改造比我最初预估的复杂得多（十个空间类型、上百个表单项），但因为是单独签的合同，我可以合理地报出7000的价格，宇哥也理解——他自己看了那份功能确认单就知道工作量有多大。

四、合同：我踩过的坑

最开始我也犹豫过要不要签合同。毕竟是朋友介绍的，搞得太正式会不会显得不信任人家？

后来想明白了：合同不是为了打官司，是为了把双方的预期对齐。什么功能做、什么功能不做、什么时候交、多少钱、改几次、怎么验收——这些事口头说过就忘了，写在纸上大家都踏实。

合同里有几个条款是我觉得必须写清楚的：

交付标准。“小程序能用"是一句废话，具体到"报价计算结果与甲方提供的单价表一致"才有意义。验收时宇哥拿着他的Excel表格，输入同样的尺寸，对比小程序算出来的结果和Excel是不是一样，一样就算通过。

免费修改的边界。我写的是"验收后15天内，调整单价、改文字、改颜色算免费修改，不超过2次；新增功能另算”。这条非常重要。没有这个边界，甲方可能觉得"顺手加个小功能"不算什么大事，但对开发者来说每个"小功能"都是时间和精力。

付款节点。50%预付、50%验收后付。做完一个阶段再开下一个。宇哥打钱很爽快，但这个规矩还是要立，万一以后遇到没这么爽快的甲方呢。

需求变更规则。免费修改范围之外的变更，需要双方另行协商费用。这条在第二阶段派上了用场——宇哥决定把支付功能推迟、先做旧房改造，我们直接改了合同内容，没有任何争议。

一个小建议：不需要找律师写合同，但核心条款一定要有。我的合同也就两页纸，但该有的都有了。

五、开发：Claude Code是主力，我是产品经理

说实话，这个项目90%的代码都是Claude Code写的。我的角色更像是一个产品经理——理解宇哥的需求，翻译成Claude能理解的任务描述，检查输出的质量，发现问题让它修。

但这并不意味着不需要技术基础。408学的那些东西——数据结构、计算机网络、操作系统的概念——在我和Claude Code协作时确实帮了大忙。至少我能看懂它写的代码是在做什么，能判断它给的方案合不合理，遇到报错也能大概定位是哪一层出了问题。

开发中几个印象深刻的坑：

小程序适配问题。代码在浏览器里跑得好好的，放到微信小程序里各种样式错乱。华为手机的状态栏比iPhone高，导致顶部导航被遮住；底部按钮在有虚拟导航条的机型上被截断。这些问题没有什么高深的解决方案，就是一个一个改、一个一个测。

Pro计划的额度焦虑。Claude Code用的是Pro计划，每5小时大约能用45条消息。听起来不少，但遇到复杂功能（比如旧房改造的上百个表单项），一个下午的额度很快就用完了。我后来学会了几个省token的技巧：对话太长就开新会话、给指令要尽量具体（“修复第42行的时间戳格式"比"修复登录bug"省好几轮对话）、在项目根目录放一个CLAUDE.md让它不用每次都重新了解项目。

一定要用Git。有好几次Claude Code改着改着把之前正常的功能改坏了，如果没有版本管理我可能要从头来过。我的习惯是每完成一个功能就commit一次，commit信息写清楚改了什么。哪次改出了问题，回滚到上一个正常的版本就行。

六、沟通：技术人和非技术人的翻译器

宇哥是做装修的，完全不懂技术，但他很清楚自己要什么。我们的沟通有一个固定的模式：他用语音或者面对面告诉我他想要什么效果，我把他的描述（有时候是他画的草图、发的CAD截图）丢给Claude，让Claude帮我生成一份结构化的需求文档，打印出来给宇哥确认。

这个流程最大的好处是宇哥不需要理解任何技术概念。他不需要知道什么是前端后端、什么是API、什么是数据库。他只需要看着需求文档说"对，我要的就是这个"或者"不对，这里应该是那样”。

有几个沟通上的经验：

永远不要用技术术语。我一开始跟宇哥说"这个功能需要后端支持"，他不明白为什么在手机上算个数还需要别的东西。后来我换了一种说法：“现在的版本是报价完了就没了，如果你想让每个客户的报价记录都存下来、以后还能查到，就需要加一台服务器，每个月大概100块的成本。“他马上就懂了。

让甲方做选择题而不是问答题。不要问"你觉得结果页应该怎么展示”，而是做两三个方案让他选。我每次都是先让Claude Code做出来，截图发给宇哥，宇哥说"这个好"或者"换那个颜色”，比口头描述高效十倍。

及时同步进度。每完成一个阶段性的成果，我都会给宇哥发个截图或者录个屏。这样做有两个好处：一是让他知道钱花在哪了，二是尽早发现理解偏差。有一次我理解的"旧房改造"和他想的差了一整个页面，幸好在开发早期就发现了，改起来成本很低。

七、交付与验收

四个阶段的交付总体上都挺顺利的。每次交付我都会先让宇哥用手机完整走一遍流程，对着他的Excel表验算几组数据，确认结果一致后在验收单上签字，然后我收尾款。

印象比较深的是第一阶段的验收。宇哥拿着手机输了一套他很熟悉的房子的数据，算出来的总价和他心算的差了一些。一项一项核对，最后发现是少乘了一个系数。改了之后就对上了。这个经历让我意识到：测试数据一定要让甲方自己提供，用他熟悉的真实案例来验证，比你自己编造测试数据靠谱得多。

尾款方面，宇哥每次都在验收当天或第二天就转了，这一点确实没得说。但我觉得这也和分阶段付款有关——每次金额不大（两三千到六千不等），付款的心理压力小，验收通过了自然就痛快打钱了。如果最后一次性收三万二的尾款，可能就没这么爽快了。

2026 年 4 月于春城昆明