常见问题：价格、周期、合同与售后，一次说清

不按工时。工时报价看着透明，其实双方都核实不了——你没法判断「这个功能要 15 人天」是真是假，我们也没法预知做到一半会冒出什么问题。更麻烦的是后期：每加一个小需求都要折算成工时再收钱，来回几次就容易扯皮，最后谁都不愿意再提改进。我们的做法是先梳理你的业务流程，评估这件事在流程上的深度与广度——涉及几个环节、几个角色、多少分支——据此给出一个固定总价。签了就不再变，我们自己估算失误不向你追加；小范围的调整和补充也不另收费。

取决于功能范围，跨度可以从几万到几十万。作为参考：纯展示型小程序或官网通常 2–5 万；带完整交易流程的商城类 5–20 万；企业内部管理系统 5–40 万；涉及多端、系统集成或私有化部署的复杂项目 40 万起。判断方法不是看总价，而是看功能清单——把你要做的功能逐条列出来，再让各家按同一份清单报价，这样才有可比性。我们在给出报价前会先做 1–2 天的需求梳理，把清单列清楚再报一个可追溯的价。

常见原因有五个：一是功能理解不同——对方可能漏听了几个模块，报得自然便宜，后期再以「变更」名义加回来；二是人力成本不同，一线城市团队和三四线城市团队的成本可能差一倍；三是用了现成模板还是纯定制；四是报价里含不含 UI 设计、测试、文档、维护期；五是有些团队用低价抢单，靠后期维护和二次开发找补。所以对比报价时不要只看数字，要对比「同一份功能清单 + 相同的交付范围」，并要求把交付物清单写进合同。

行业惯例是 30% 预付、40% 中期、30% 验收后付尾款，具体切分依项目节奏调整。我们的做法是分三期：签合同付 30%，原型确认、开发完成并交付可测试版本时付 50%，验收上线后付 20%。关键原则是每一期都对应一个你已经确认收到的成果，而不是按时间付款。如果对方要求一次性付全款或预付超过 50%，这是需要警惕的信号。

主要是三项：服务器与域名（通常每年几百到几千元，视访问量）、第三方服务费（短信、推送、地图、支付通道等按用量计）、以及维护费。我们提供 12 个月免费缺陷修复，期满后不强制收年度维护费——你有需要时单独找我们，按次评估报价。另外 App 类项目还有苹果开发者账号 99 美元/年、小程序认证费 300 元/年这类固定支出。这些在交付时会给你一份完整的年度成本清单，不会有隐藏收费。

算一笔账：招一名中级全栈工程师的年成本（薪资 + 社保 + 办公 + 设备）通常在 25–40 万，而且要从零搭建前后端、测试、产品的能力至少需要 3–5 人。如果只是一个阶段性项目，这笔投入很难跑正。外包的优势是成本一次性、随用随停。但如果你的软件就是公司核心竞争力、需要持续高频迭代三年以上，组建自有团队会更合适。我们遇到后者时会如实建议你招人，而不是硬接这个项目。

包含。UI 设计是报价的一部分，不在报价之外单独收费——你不需要在设计上再做一次预算决策，也不会遇到「做到一半才说设计要另收费」的情况。流程是先出设计稿给你确认，再做前端实现，界面最终以交付上线的页面为准。需要说明的是，报价里的设计工作量和项目复杂度是匹配的：页面多、状态分支多，设计和实现的工作量都会随之上升，这部分已经算在总价里。如果你已有品牌视觉规范或现成设计稿，我们按你的执行，成本会相应减少。

轻量项目（展示型小程序、官网）4–8 周；标准业务系统 2–4 个月；复杂系统（多端、系统集成、生产制造类）4 个月以上。需要注意周期主要消耗在需求梳理、原型确认和测试上，而不是编码本身——把流程图和权限矩阵确认清楚往往占项目前 20%–30% 的时间，这部分投入不能省。另外 App 上架审核要预留 2–3 周缓冲，ICP 备案需要 10–20 个工作日。

因为你在动手前几乎不可能想清楚所有需求——这不是能力问题，是软件的固有特性。用户只有真正用上系统，才知道哪些功能有用、哪些是多余的、还有什么是当初没想到的。一次性做半年再上线，很可能有一半工作量是浪费的。我们的建议是先用 1–2 个月做出核心流程的可用版本上线，拿真实反馈决定下一步。这样总投入通常更低，上线更早，风险也小得多。

能，而且不应该是「看文档」那种看。我们的做法是每周固定时间同步一次，同时给你一个部署在测试环境、当下就能点开运行的版本。你可以自己在手机上实际操作，而不是听我们汇报「完成了 80%」。每周还会附一份进度说明：这周完成了什么、下周做什么、有没有风险项。这套机制写进合同，不是靠自觉。

12 个月内因程序缺陷导致的问题免费修复。响应时效写进合同：工作日 4 小时内响应，影响主流程的问题当天处理。需要区分「缺陷」和「新需求」——程序没按约定实现叫缺陷，免费；上线后要求增加原本不在范围内的功能叫新需求，按变更流程报价。这个界限在合同和功能清单里会写清楚，避免争议。

同时推进的项目不多，这是我们刻意控制的——项目一多，每个人的注意力就会被摊薄，交付质量和响应速度都会下滑。所以启动时间需要排期，我们会如实告诉你最早能开始的时间，而不是先答应了再拖延。如果你有明确的时间要求，早点说，我们按排期给你答复。

不会，因为我们的报价不是按工时算的——这恰恰是很多项目扯皮的根源。小范围的调整和补充我们不另收费，真实项目不可能一个字都不改，为这种改动单独收钱对双方都是消耗。只有当你新增的功能明显扩大了范围（比如多出一套角色权限、或一条完整业务线），我们才会重新评估，并且先说明为什么算超出、加多少钱，你确认后才做。你也可以随时叫停、缩小范围或延到二期。

归你。定制开发在法律上属于委托开发，我们会在合同里明确约定著作权归委托方（也就是你方）所有，源码、数据库结构、文档全部交付，无加密、无授权限制、无后门。你可以自行申请软件著作权登记，我们会提供登记所需的源码与文档材料。那种「源码给你但核心模块用加密狗锁住」的做法，我们不使用。

登记本身需要 30–60 个工作日（可加急）。申请主体是你方（因为著作权归你），我们负责提供全套材料：源代码文档（前后各 30 页）、用户手册、设计说明书。如果你要上架安卓应用市场，软著是必需的资质，建议在开发进行到一半时就启动申请，不要等上线前才想起来，否则会卡住上架进度。

重点看六项：一是功能范围（附功能清单作为附件，这是最重要的）；二是交付物清单与验收标准；三是付款节点与条件；四是知识产权归属；五是维护期长度与响应时效；六是违约与终止条款，特别是「中途终止时已完成部分的归属与结算方式」。如果一份合同里只有总价和工期，没有功能清单附件，后期几乎必然扯皮。

归你。我们按里程碑交付源码——每个阶段完成时你都会拿到当时可运行的完整代码，并且代码托管在你名下的仓库里。这意味着即使合作中断，你也拿得走已完成的所有成果，不会出现「付了钱但东西不给」的情况。结算上按已完成并经你确认的里程碑付款，未开始的阶段不收费。

会，而且欢迎。开发过程中你会向我们披露业务流程、客户数据、供应商信息等敏感内容，签 NDA 对双方都是保护。我们默认可以签你方提供的版本，也可以提供我们的模板。涉及数据处理的，还会在合同里约定数据用途限制、存储位置和销毁方式——尤其是 AI 类项目，这些条款很关键。

可以有一个折中做法：先签一份简短的《需求评估协议》，我们免费或低成本帮你做需求梳理和方案，这个阶段双方投入都很小、退出成本也低。但一旦进入实际开发，必须签正式合同并明确功能范围。不签合同就开始写代码，对双方都是风险——你没有依据要求交付内容，我们也没有依据界定范围边界。

能，而且大多数客户一开始都说不清楚——这很正常，你懂业务但不需要懂技术。你只要能回答三个问题就够了：想解决什么问题、现在是怎么处理的、希望达到什么效果。剩下的需求梳理是我们的工作：通过访谈、看现有的表格和流程，把它整理成功能清单和可点击原型给你确认。你不需要先写出一份规范的需求文档。

绝大多数项目可以远程完成。需求调研阶段我们建议至少有一次现场或视频深度沟通，把业务流程过一遍，之后每周线上同步即可。需要驻场的情况通常是：业务极其复杂需要长时间贴身梳理、或者甲方有数据不出内网等合规要求。驻场会显著增加成本，所以只在确实必要时才建议。

问四个问题，看对方怎么答：一是「源码交付吗，有没有加密」；二是「这个报价对应哪些功能和流程，能给一份清单吗」；三是「如果我中途换团队，接手需要多久」——答案越坦然越可信；四是「有没有你们劝客户不要做的案例」——只会说「都能做」的团队，通常也没能力说「这个不该做」。

我们接的四类：小程序与 App 定制、企业官网与营销站、企业内部管理系统、AI 智能体与落地咨询。不接的主要有三类：一是纯粹的低价模板站（我们做不过流水线工厂，也不想做）；二是需要我们垫资或按效果分成的项目；三是预期严重不合理的项目——比如预算 3 万要做一套完整 ERP，这种项目接下来双方都会痛苦，不如提前说清楚。

日常运营层面完全可以。内容更新、用户管理、审批流调整、基础数据维护这些都在管理后台里操作，交付时提供使用说明文档和录屏培训，你或行政同事都能上手。需要技术能力的部分（服务器运维、数据库备份、版本升级、新功能开发）建议由我们负责，已包含在免费维护期内。如果贵司有技术人员，我们也会交付完整的运维文档供其接手。

要看数据敏感度和部署方式。三种选择：一是公有云 API（成本最低，数据会经第三方服务器，适合非敏感场景如文案生成）；二是私有化部署开源模型（数据完全不出内网，适合客户资料、财务、合同等敏感数据，硬件投入较高）；三是混合方案，敏感数据留内网用本地模型处理，非敏感任务走云端。另外无论哪种方式，都可以先做脱敏——把姓名、手机号、金额等字段替换后再送给模型。这个选择在方案阶段就会确定，不会开发完了才讨论。

找一个可量化的切口，而不是算「提升多少效率」这种虚的。可行的方法是：选一个高频、规则明确、当前耗时可测量的环节（比如客服首响时间、单据录入耗时、周报撰写时长），记录现状基线，上线后对比同一指标。如果这个环节每月能省 40 小时人力，按人力成本折算就是可验证的回报。我们建议第一个 AI 项目只瞄准一个这样的环节，做成了再复制——不要一上来就规划「全公司 AI 转型」。

三个常见原因。一是场景选错——挑了一个本来就不痛、只是听起来很酷的环节，员工用不用无所谓。二是工作流没改——只是多给了一个 AI 工具，员工要额外花时间学它、还要在两个系统间来回切，反而更麻烦。三是把它当项目而不是当能力，验收完就结束了，没有陪跑期。所以我们的 AI 项目里，培训和工作流重构是标准交付的一部分，不是可选项。

不是。选型要匹配任务难度：简单的分类、抽取、改写任务用小模型就够，成本可能只有旗舰模型的几十分之一；只有复杂推理、长文档理解、需要高准确率的场景才值得用最贵的模型。我们的做法通常是多模型组合——简单任务走便宜模型，难的转给强模型，再配合缓存和批处理进一步降本。另外架构上会做成模型无关，明年出了更好的模型可以直接替换，不用重写业务逻辑。

POC（概念验证）是用小成本、短周期验证「这件事到底能不能做成」的一次性实验，通常 2–4 周。AI 项目的不确定性远高于传统软件——同样一个需求，换个行业、换份数据，效果可能天差地别。直接签大合同做完整系统，万一效果不达预期，损失是几十万；先花几万做 POC，用真实数据跑一遍，验证了再投入。POC 结束后如果结论是「这个场景不适合用 AI」，那这笔钱花得也很值。

抵触通常来自两个原因：怕被替代，以及觉得「学了更麻烦」。前者靠管理沟通解决，要明确说清 AI 是用来接掉重复劳动、不是用来裁人；后者只能靠让工具真的好用——把 AI 嵌进员工本来就在用的流程里（比如企业微信、现有的业务系统），而不是让他们再多打开一个网站。我们的培训会按岗位设计具体工作流，让员工当场用它处理自己手头的真实任务，当场感受到省事，比讲十遍道理有用。