低成本建站：内部工时怎样计入自建方案的真实成本
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /4f3ace982c90.html
📄
低成本建站：内部工时怎样计入自建方案的真实成本
把内部工时计入自建方案时，关键不是给每小时定一个价，而是先判断这笔工时是否真的挤占了别的产出。如果做站的人本来就有闲置时间，且上线后不需要持续投入，那么工时更适合当作沉没投入来记录；如果做站的人因此推迟了能带来收入的工作，或者上线后每月仍要花时间维护，就必须按机会成本计入，否则自建看起来省钱，实际是在用另一项收入补贴建站。下面按这两种条件分别展开。
条件一：工时来自闲置时间且上线后投入收敛
这种情况下，内部工时不需要按对外报价折算。理由很直接：这段时间原本没有产生收入，用它来搭建并不减少任何既有收益，把它乘上一个虚构的小时费率，只会让预算表失真，让人误以为自建比实际更贵。
但仍要做一件事：把工时按阶段记录下来，作为后续判断的依据。建议只记三个数——搭建总小时、上线后第一个月的维护小时、之后每个月的维护小时。记录动作本身要轻，用一张表按日期累加即可，不要为记录再引入一套工具。
假设某方案搭建用了四十小时，全部来自晚间闲置时间，上线后每月维护两小时，且这两小时不影响任何有收入的工作。此时工时应记为沉没投入，预算表里只体现域名、托管等直接支出。下一步的判断依据是维护小时的变化趋势：如果连续两个月维护时间明显上升，说明已经滑向第二种条件，需要重新计入。
条件二：工时挤占有收入的工作或维护不收敛
只要满足以下任一条，就应按机会成本计入：搭建期间推迟了有明确收入的工作；上线后维护时间每月都要占用工作时间；维护需要特定技能，而具备该技能的人同时承担其他交付任务。
计入方法不必追求精确，用可验证的替代口径即可。取该人员被挤占的那类工作的单位时间产出，乘以实际占用小时，得到的就是这笔工时的机会成本。这个数字的作用不是算总账，而是用来和外包报价、现成方案的年费做同口径比较。
这里有一个容易被忽略的例外：即使工时来自闲置时间，如果上线后需要长期占用工作时间处理安全更新、插件兼容或内容调整，那么应按维护部分计入机会成本，搭建部分仍可视为沉没投入。也就是说，同一方案里两部分工时的处理方式可以不同，不必强行统一。
用一次比较决定是否继续自建
把两种口径分别算出来，再做一次对照：
- 沉没口径：只计直接支出，用于判断“这件事值不值得做”。
- 机会成本口径：直接支出加上被挤占工时的替代产出，用于判断“继续自建是否比换方案更划算”。
如果两个口径的结论一致，直接按结论走。如果结论相反，说明决策对工时假设很敏感，此时应优先降低不确定性，而不是先选方案。具体动作是：先记录两周的实际维护小时，再据此重算机会成本口径。两周数据足以暴露维护时间是否收敛，也能看出是否出现了计划外的返工。
需要说明的是，维护时间上升并不自动等于自建失败。它也可能来自内容更新加快、访问量变化或新增功能需求，这些属于业务变化而非方案缺陷。区分方法是看时间花在哪里：如果集中在修复故障和兼容问题，偏向方案本身的持续成本；如果集中在新增内容和功能，偏向业务投入，应单独归类，不要混进方案成本里。
记录方式与常见误判
工时记录只需覆盖到能支撑上面这次比较即可，不必精细到分钟。按“日期、阶段、小时、是否占用工作时间”四列记录，阶段分为搭建、故障处理、内容更新、功能新增四类。这样分类的好处是，后续重算时可以直接把故障处理类归入方案成本，把内容更新和功能新增类归入业务投入，避免把业务增长的成本算到方案头上。
两个常见误判值得避开。一是把内部工时按对外报价折算，这会让自建方案在纸面上永远不划算，从而放弃一个本来合适的选项。二是完全不记工时，导致上线半年后无法回答“时间到底花在哪”，只能凭印象判断，容易在维护变重时迟迟不换方案。两种误判的修正方式都是回到记录：先有分类数据，再决定是否调整。
最后，工时计入方式一旦确定，应同步写进方案的交接说明里，注明哪些工时按沉没处理、哪些按机会成本处理、依据是什么。这样在人员变动或方案重估时，接手的人能看懂原来的判断前提，而不是从零重新争论一遍。
