1. 背景为什么 AI 团队需要关注研发税收抵免1.1 研发税收抵免到底是什么在 AI 项目交付过程中大部分研发团队的注意力都集中在模型效果、推理性能和上线时间上很少有人会认真思考一个问题当前投入的大量人力与算力成本在财务层面是否还能带来额外的价值以美国联邦研发税收抵免Federal RD Tax Credit为例这是一个存在了几十年的税收激励政策对应《国内税收法典》第 41 条Internal Revenue Code Section 41。它的核心逻辑很简单企业从事合格研究活动Qualified Research Activities时发生的合格研究费用Qualified Research ExpensesQRE可以直接从应纳税额中抵扣一部分。这里要区分两个概念税前扣除Deduction减少的是应纳税所得额省下的钱 费用 × 税率。税收抵免Credit减少的是最终应缴税款省下的钱 费用 × 抵免比例。税收抵免的价值更高。举例来说如果公司在研发上花了 10 万美元税前扣除只能按公司税率比如 21%省下 2.1 万美元而税收抵免则是在扣除之外再按符合条件的研发费用计算直接抵减税款。这项政策最早确立于 1981 年中间经过多次延续和修订2015 年后成为永久性激励。它的适用范围并不局限于实验室或物理科学研究软件开发长期以来都是这项政策的重点支持领域。而定制 AI 开发恰好是“软件开发 科研探索”的结合体。1.2 定制 AI 开发的成本结构隐藏着机会一个典型的定制 AI 项目成本结构通常是这样的成本类别占比大致区间说明算法工程师工资50% - 70%核心人力投入GPU/CPU 云计算资源15% - 30%训练、评测、推理调优数据采集与标注5% - 15%外包或内部标注团队软件许可与工具2% - 8%框架、平台、第三方 API可以看到最大的两块成本——人力和算力——正好是研发税收抵免重点关注的可计入费用。换句话说AI 团队在研发上烧掉的每一笔钱都有机会通过合规申报拿回一部分利益变相降低研发的实际成本。1.3 哪些读者适合读这篇文章这篇文章面向的对象很明确AI 项目技术负责人和研发 Leader负责 AI 产品预算与成本核算的财务或项目管理人员在海外市场有研发投入、关注税务合规的创业团队想了解“研发投入如何沉淀为可复用工程资产”的开发工程师。要提前说明的是本文属于技术科普与工程实践整理不构成专业税务意见。美国联邦层面的认定有严格标准各州对研发税收抵免的处理也存在差异实际申报必须由具备资质的税务顾问或注册会计师结合企业真实情况完成。2. 核心概念合格研发的四项认定标准2.1 四项测试分别是什么根据 IRS 的认定框架一项活动要被认定为合格研发需要同时满足四个条件也就是常说的 four-part test第一消除技术不确定性Elimination of Uncertainty。在项目开始时团队不知道某个技术方案是否可行不知道具体该怎么实现或者不确定哪种方案最优。这种“不确定性”是技术层面的而不是商业层面的。第二采用试验过程Process of Experimentation。团队通过构建模型、测试原型、运行实验、分析结果等一系列迭代操作来评估和验证备选方案而不是直接照搬已经存在的已知方案。第三基于技术基础Technological in Nature。活动必须建立在计算机科学、工程学、数学、物理学等自然科学或工程技术之上。第四符合合格的研究目的Qualified Purpose。目标是开发新的或改进的业务组件比如让系统更智能、更快、更准、更稳定、更易用。四个条件必须同时满足。这也意味着不是所有“和 AI 沾边”的工作都能被认定。2.2 用一个 AI 项目对照四项测试为了便于理解我们假设团队正在为客户构建一个基于 Transformer 架构的文档智能问答系统。我们逐条对照技术不确定性直接微调开源模型还是设计一套混合检索 重排 生成的 RAG 框架在业务数据分布不明确的情况下没有现成答案。甚至连 embedding 选型、chunk 切分粒度、重排模型选择都存在大量未知。试验过程团队分别测试了不同 chunk 切分策略256 / 512 / 1024 token、不同 embedding 模型bge、text-embedding-3、不同 Top-K 参数构建了 2000 条测试集记录了准确率、召回率和延迟逐步收敛到最优方案。技术基础涉及自然语言处理、深度学习、信息检索、工程性能调优全部属于计算机科学范畴。研究目的提升问答准确率、降低检索延迟、改善用户交互体验。对照下来这个项目的核心研发工作基本都落在合格研发范围内。这也是为什么“定制 AI 开发通常符合联邦研发税收抵免资格”这句话是成立的——因为定制开发本质上就是在做技术探索和方案验证。2.3 内部使用软件的特殊门槛在 AI 项目中一个特别容易踩坑的地方是“内部使用软件Internal Use Software”的认定。如果 AI 系统只用于企业内部业务流程例如内部客服机器人、内部报表分析助手、内部流程自动化工具那么 IRS 对它的认定标准会更高通常需要同时证明软件具有创新性产生了显著的改进开发涉及重大的经济风险该软件无法通过购买现成方案满足业务需求。反过来如果 AI 能力是嵌入到对外销售的 SaaS 产品、硬件设备、定制交付物中或者是用于企业对外提供的服务流程中认定的空间就会大很多。所以在项目一开始技术负责人就要做一个前置判断这个 AI 系统是“对外交付”还是“对内使用”这个判断直接决定了未来申报的口径和证据准备策略。3. 定制 AI 开发中的合格活动类型3.1 更容易被认定为研发的活动在定制 AI 开发项目中以下活动通常具备较高的合格性算法设计与模型选型。对不同模型架构进行对比实验验证它们在特定业务数据上的效果记录评估指标。例如在同一批数据上对比 BERT、RoBERTa、DeBERTa 的微调效果结论不是显而易见的需要靠实验数据说话。特征工程与数据实验。围绕数据质量、特征提取方式、标注策略开展的系统性试验。例如测试不同正则化规则对实体识别效果的影响比较规则清洗与模型清洗的收益差异。模型训练与超参数调优。通过网格搜索、随机搜索、贝叶斯优化等方式寻找最优参数组合。这本质上是典型的“试验过程”提出假设、设计实验、分析结果、调整参数。推理性能优化。针对 GPU 或 CPU 环境试验模型量化INT8 / FP16、剪枝、知识蒸馏、批处理策略、服务框架选型等。硬件配置和模型结构的不同组合会带来完全不同的性能表现属于典型的技术不确定性。数据管道架构探索。设计可扩展的实时或离线数据处理架构验证分布式训练、数据加载、缓存策略等方案的可行性。评估体系建设。构建包含准确率、召回率、F1、延迟、成本等多维度的自动化评估框架。评估维度如何权衡、如何设计测试集本身就是一个需要实验验证的研发问题。这些活动的共同特征是“探索未知”而不是“执行已知流程”。3.2 难以计入的活动反过来下面这些工作通常不被认定为合格研发直接调用成品模型的 API不做任何自定义修改和微调按照开源项目的文档一步步部署不涉及方案修订和技术验证常规的 Web 前端页面开发、数据库表结构日常维护为了兼容旧版本进行的固定式补丁修改纯非技术性的需求沟通会、项目管理会议、内部协调为生产环境做的例行监控、告警配置、容量规划。这些工作不是不重要而是在做费用归集时应该从研发工时里区分开。如果把大量非研发工时混入申报口径反而会影响整个项目证据链的可信度得不偿失。3.3 边界场景的判断清单实际项目中大量工作处于灰色地带。我的建议是判断标准不取决于岗位名称不取决于项目名里有没有 AI而是取决于这项工作是否为了消除技术不确定性而设计了试验。你可以为项目建立一个简单的问题清单项目启动时我们是否不知道最终技术方案是什么团队是否尝试了至少两种以上的技术路线或参数组合最终决策是否基于实验结果而不是经验猜测实验过程中是否形成了可追溯的版本记录和结果数据任何一个问题的答案是“否”相关工时就要谨慎计入。4. 可计入的费用类型与成本拆分4.1 工资与人力成本研发人员的工资是最大的可计入费用包括研发工程师、算法工程师、数据科学家以及直接参与合格研发活动的技术管理人员的工资和税务成本。这里有一个关键点计入的是“投入到合格研发活动的时间比例”对应的工资而不是岗位全额工资。一个算法工程师既做模型实验又做生产环境维护那么只有用于模型实验的那部分工时对应的工资才能纳入 QRE。这也就是为什么工时记录如此重要——没有工时记录就无法拆分财务只能选择全部排除或按一个模糊比例估算最终结果往往远低于实际应得的抵免金额。4.2 云计算、算力与数据成本在当前的税法框架下云服务费用在满足条件时可以作为合格研发费用的一部分。GPU 训练服务器、模型评测用的推理资源、实验数据存储、对象存储中用于训练集和测试集的数据访问成本都有可能被纳入可计入费用。但需要注意两点只有“用于试验和研发”的那部分算力可以计入。生产环境的推理服务、监控告警、日常运维资源都不属于研发费用。云资源的可追溯性很重要。如果公司所有资源都放在同一个账号下没有任何项目标签财务根本无法区分哪部分是实验消耗、哪部分是生产消耗。这会导致审计时大量费用被剔除。4.3 委托研究与第三方服务如果把部分研发工作外包给高校实验室、独立算法团队、第三方数据标注公司相关费用的 80% 可以作为合同研究费用Contract Research Expense计入。判断依据是外包工作的目的是否是帮助公司完成合格研发活动。同时参与确认和监管的外包工作需要保留技术协议、交付成果、验收记录证明这笔外包支出确实服务于研发目标。4.4 不建议计入的部分办公场地租金、行政管理成本、销售和市场营销费用、业务推广支出这些都不属于合格研发费用。即使项目名义上包含较多算法工作费用归集也必须严格按税法口径执行不能把公司整体运营成本都“摊”进研发费用里。5. 实战建立一套 AI 研发费用追踪体系这是最有工程价值的部分也是很多团队最容易忽略的部分。研发税收抵免的申报不是项目做完之后凭记忆“估算”出来的而是在开发过程中留下足够多的可审计证据。下面从工程视角搭建一套可落地的追踪体系。5.1 第一步项目立项时建立研发标记在项目管理工具Jira、Trello、GitHub Issues 等中为每个任务增加一个自定义字段例如rd_flag取值可以是eligible合格研发活动non_rd非研发活动mixed混合活动部分工时属于研发。建议在团队任务模板里加入一段说明文字这个任务是否涉及技术不确定性的探索 如果是预计的备选方案有哪些如何验证 请在选择完成后将实验结论记录到团队知识库。这样做的目的是在任务创建的时候就完成一次研发性质的初步判断而不是等季度结束再靠回忆补标记。任务标记是后面所有费用归集的起点。5.2 第二步工时记录与实验日志要求核心开发人员按周填写工时拆分粒度到项目或任务级别。同时要有实验日志作为支撑。Git 提交记录是天然的研发活动旁证。下面给出一个 Python 脚本示例用于从 Git 仓库统计每个开发者每日的提交次数作为“研发活动确实发生”的辅助证据import subprocess from collections import defaultdict repo_path /path/to/your/ai-project start_date 2025-01-01 end_date 2025-03-31 cmd [ git, -C, repo_path, log, --since, start_date, --until, end_date, --format%H|%ad|%an, --dateshort ] output subprocess.check_output(cmd, textTrue) records defaultdict(set) for line in output.strip().splitlines(): if not line: continue commit_hash, date, author line.split(|) records[(author, date)].add(commit_hash) for (author, date), commits in sorted(records.items()): print(f{author}\t{date}\t{len(commits)} commits)输出示例zhangsan 2025-01-06 12 commits zhangsan 2025-01-07 9 commits wangwu 2025-01-08 15 commits注意这份统计不是用来直接替代工时表而是作为“该员工确实在这一天从事了代码相关研发活动”的客观佐证。要让工时记录真正可靠建议每周五花 10 分钟填写工时不要拖到月底工时拆分与 Git 活动保持基本一致禁止追溯填写超过 30 天前的记录避免“估算式工时”工时表中的任务 ID 要与项目管理工具中的任务一一对应。5.3 第三步费用归集与技术文档沉淀建议每月整理一次研发费用台账核心字段包括字段说明项目名称与立项记录一致任务 ID对应 Jira/GitHub Issue 编号负责人实际执行人研发工时按小时计人工费用工时 × 工资折算云资源费用按项目标签拆分外包合同金额80% 计入基数关键交付物实验报告、模型文件、评估结果与此同时技术文档的沉淀同样重要。以下文档都可以作为研发活动的支持材料实验方案设计文档评估结果对比表模型或算法选型决策记录Decision Record代码仓库的 tag 和 release notes实验管理平台MLflow、WB 等导出的 run 记录。下面是一个适合 AI 团队的实验记录 Markdown 模板# 实验记录模板 ## 项目名称 文档智能问答系统 ## 实验日期 2025-02-10 ## 要消除的技术不确定性 - 不同 embedding 模型对中文长文检索效果的影响 - RAG 检索 Top-K 参数对答案准确率的影响 ## 实验方案 - 准备 2000 条测试问句覆盖 5 类业务场景 - 对比 bge-large-zh 与 text-embedding-3 的检索效果 - 固定重排模型分别测试 Top-K 3 / 5 / 10 ## 结果与结论 - bge-large-zh 在 F1 上高 4.2%但延迟高 35ms - 选择 Top-K 5 作为生产默认参数 - 完整结论写入 docs/decision-log.md ## 相关代码 - experiments/embedding_compare.py - experiments/retrieval_config.yaml这个模板的价值在于它把“不确定性是什么、怎么试验、结果如何”完整记录下来天然满足研发认定所需的证据要求。同时它也是团队本身需要的工程文档一鱼两吃。5.4 第四步季度复盘与证据归档建议每季度做一次复盘由技术负责人和财务人员一起核验研发工时是否与实际项目进展匹配云资源账单是否按项目正确拆分实验文档是否齐全是否覆盖所有标记为 eligible 的任务新启动的项目是否都完成了研发标记离职员工的未归档文档和代码是否已经沉淀到仓库证据保留周期建议在 5 年以上以应对可能的事后审查。这里特别强调企业应遵循“真实、准确、完整”的原则进行归档不夸大、不虚增每一项数据都应能互相印证。6. 常见问题与排查思路下面整理一些团队在实际操作中最常遇到的问题。问题现象常见原因解决思路财务说“研发费用不达标”工时记录缺失无法拆分建立周工时制度按任务拆分到小时申报时算法工时被剔除没有实验文档无法证明试验过程每周维护实验日志记录假设、方案、结果云账单无法拆分到项目所有资源用同一个账号没有打标签建立云资源命名与标签规范按项目维度拆分Git 记录与工时表不一致开发使用个人分支长期不推送规定每日推送避免批量提交内部使用软件被认定不符合系统只服务内部流程评估业务形态或按更高标准准备创新性证据项目结束后补工时记录记录缺失靠回忆估算禁止事后补录按月沉淀证据外包费用全额计入不理解合同研究费用的规则了解外包费用 80% 计入基数的规则如果你遇到报错或问题可以按下面顺序排查先检查任务标记是否准确是否存在明明做了研发却标记为 non_rd 的情况再核对工时记录是否完整是否覆盖所有 eligible 任务然后检查云资源标签、合同发票是否齐全最后看实验文档和 Git 记录能否互相验证。7. 最佳实践与工程建议7.1 把研发证据融入日常开发流程最理想的状态是研发人员不需要做太多额外工作因为工具链本身就留下了痕迹。建议从以下几个点入手Git 提交信息采用约定式提交feat、fix、experiment、evaluate等前缀让实验类提交一眼可识别实验脚本统一存放在仓库中建立experiments/目录每个实验一个子目录包含脚本、配置和结果云资源强制打标签建立project:xxx、env:train/test/prod、purpose:research/production的标签规范关键决策记录ADR模型选型、架构调整等重大决策在docs/decisions/下记录决策背景和备选方案。这些动作本身就是为了提升工程质量和可复现性和税务申报并不冲突。把它当作“顺手而为”的工程规范而不是“额外的合规负担”团队接受度会高很多。7.2 与财务、税务顾问的协作节奏研发税收抵免不是技术团队单方面能完成的事情。建议建立固定的协作节奏立项时同步研发标记规则让财务知道哪些任务属于合格研发每月同步一次费用台账包括工时汇总和云费用拆分季度例会核对申报范围和工时解决边界争议申报季前由税务顾问提前审阅证据是否充分留出补充时间。这样做的好处是税务顾问不会在最后一刻才发现证据不足而是能在一个持续更新的证据池上工作申报质量和效率都会显著提升。7.3 合规与风险边界最后想强调一下研发税收抵免的申报是基于真实研发活动的权益申请不是财务游戏更不是税收漏洞。以下几点是底线任何团队都应该遵守严禁虚增研发工时或费用严禁为了抵免而伪造实验记录或 Git 提交各项数据必须能够互相印证工时、Git 记录、实验文档、云账单应保持一致对认定有疑问的边界项目主动向税务顾问咨询而不是抱着“先报了再说”的心态涉及多国税务安排时应咨询当地专业顾问确保在合法合规的框架内操作。8. 总结与行动建议梳理一下全文的关键信息定制 AI 开发天然具备大量“消除技术不确定性”的活动与研发税收抵免的认定逻辑高度匹配但不是所有 AI 相关工作都能计入内部使用软件、常规维护、配置性工作通常要排除人工、云计算、委托研究是三类主要可计入费用但需要严格的区分和证据支撑。最终建议很简单每个 AI 团队从今天开始做三件事。第一给正在进行的项目打上研发标记明确哪些任务是 eligible、哪些是 non_rd。第二建立简单的周工时记录规则把工时拆分的粒度从“项目”下沉到“任务”。第三把实验记录模板发给团队成员让每次实验都留下“不确定性—试验过程—结果结论”的完整记录。这些事不需要一步到位先跑起来再逐步完善。研发抵免并不是遥不可及的财务操作它本质上是对“团队正在做的真实技术探索”的一次系统化记录。把这些记录做好了工程资产也更扎实无论是未来申报、融资尽职调查还是技术团队交接都会受益。如果本文对你有帮助可以收藏备用也欢迎在评论区交流你的 AI 项目在研发管理和成本核算上的实践经验。 
长河君 · 2026/8/29 1:30:00 · 阅读 1.2k AI团队如何通过研发税收抵免降低定制开发成本
1. 背景为什么 AI 团队需要关注研发税收抵免1.1 研发税收抵免到底是什么在 AI 项目交付过程中大部分研发团队的注意力都集中在模型效果、推理性能和上线时间上很少有人会认真思考一个问题当前投入的大量人力与算力成本在财务层面是否还能带来额外的价值以美国联邦研发税收抵免Federal RD Tax Credit为例这是一个存在了几十年的税收激励政策对应《国内税收法典》第 41 条Internal Revenue Code Section 41。它的核心逻辑很简单企业从事合格研究活动Qualified Research Activities时发生的合格研究费用Qualified Research ExpensesQRE可以直接从应纳税额中抵扣一部分。这里要区分两个概念税前扣除Deduction减少的是应纳税所得额省下的钱 费用 × 税率。税收抵免Credit减少的是最终应缴税款省下的钱 费用 × 抵免比例。税收抵免的价值更高。举例来说如果公司在研发上花了 10 万美元税前扣除只能按公司税率比如 21%省下 2.1 万美元而税收抵免则是在扣除之外再按符合条件的研发费用计算直接抵减税款。这项政策最早确立于 1981 年中间经过多次延续和修订2015 年后成为永久性激励。它的适用范围并不局限于实验室或物理科学研究软件开发长期以来都是这项政策的重点支持领域。而定制 AI 开发恰好是“软件开发 科研探索”的结合体。1.2 定制 AI 开发的成本结构隐藏着机会一个典型的定制 AI 项目成本结构通常是这样的成本类别占比大致区间说明算法工程师工资50% - 70%核心人力投入GPU/CPU 云计算资源15% - 30%训练、评测、推理调优数据采集与标注5% - 15%外包或内部标注团队软件许可与工具2% - 8%框架、平台、第三方 API可以看到最大的两块成本——人力和算力——正好是研发税收抵免重点关注的可计入费用。换句话说AI 团队在研发上烧掉的每一笔钱都有机会通过合规申报拿回一部分利益变相降低研发的实际成本。1.3 哪些读者适合读这篇文章这篇文章面向的对象很明确AI 项目技术负责人和研发 Leader负责 AI 产品预算与成本核算的财务或项目管理人员在海外市场有研发投入、关注税务合规的创业团队想了解“研发投入如何沉淀为可复用工程资产”的开发工程师。要提前说明的是本文属于技术科普与工程实践整理不构成专业税务意见。美国联邦层面的认定有严格标准各州对研发税收抵免的处理也存在差异实际申报必须由具备资质的税务顾问或注册会计师结合企业真实情况完成。2. 核心概念合格研发的四项认定标准2.1 四项测试分别是什么根据 IRS 的认定框架一项活动要被认定为合格研发需要同时满足四个条件也就是常说的 four-part test第一消除技术不确定性Elimination of Uncertainty。在项目开始时团队不知道某个技术方案是否可行不知道具体该怎么实现或者不确定哪种方案最优。这种“不确定性”是技术层面的而不是商业层面的。第二采用试验过程Process of Experimentation。团队通过构建模型、测试原型、运行实验、分析结果等一系列迭代操作来评估和验证备选方案而不是直接照搬已经存在的已知方案。第三基于技术基础Technological in Nature。活动必须建立在计算机科学、工程学、数学、物理学等自然科学或工程技术之上。第四符合合格的研究目的Qualified Purpose。目标是开发新的或改进的业务组件比如让系统更智能、更快、更准、更稳定、更易用。四个条件必须同时满足。这也意味着不是所有“和 AI 沾边”的工作都能被认定。2.2 用一个 AI 项目对照四项测试为了便于理解我们假设团队正在为客户构建一个基于 Transformer 架构的文档智能问答系统。我们逐条对照技术不确定性直接微调开源模型还是设计一套混合检索 重排 生成的 RAG 框架在业务数据分布不明确的情况下没有现成答案。甚至连 embedding 选型、chunk 切分粒度、重排模型选择都存在大量未知。试验过程团队分别测试了不同 chunk 切分策略256 / 512 / 1024 token、不同 embedding 模型bge、text-embedding-3、不同 Top-K 参数构建了 2000 条测试集记录了准确率、召回率和延迟逐步收敛到最优方案。技术基础涉及自然语言处理、深度学习、信息检索、工程性能调优全部属于计算机科学范畴。研究目的提升问答准确率、降低检索延迟、改善用户交互体验。对照下来这个项目的核心研发工作基本都落在合格研发范围内。这也是为什么“定制 AI 开发通常符合联邦研发税收抵免资格”这句话是成立的——因为定制开发本质上就是在做技术探索和方案验证。2.3 内部使用软件的特殊门槛在 AI 项目中一个特别容易踩坑的地方是“内部使用软件Internal Use Software”的认定。如果 AI 系统只用于企业内部业务流程例如内部客服机器人、内部报表分析助手、内部流程自动化工具那么 IRS 对它的认定标准会更高通常需要同时证明软件具有创新性产生了显著的改进开发涉及重大的经济风险该软件无法通过购买现成方案满足业务需求。反过来如果 AI 能力是嵌入到对外销售的 SaaS 产品、硬件设备、定制交付物中或者是用于企业对外提供的服务流程中认定的空间就会大很多。所以在项目一开始技术负责人就要做一个前置判断这个 AI 系统是“对外交付”还是“对内使用”这个判断直接决定了未来申报的口径和证据准备策略。3. 定制 AI 开发中的合格活动类型3.1 更容易被认定为研发的活动在定制 AI 开发项目中以下活动通常具备较高的合格性算法设计与模型选型。对不同模型架构进行对比实验验证它们在特定业务数据上的效果记录评估指标。例如在同一批数据上对比 BERT、RoBERTa、DeBERTa 的微调效果结论不是显而易见的需要靠实验数据说话。特征工程与数据实验。围绕数据质量、特征提取方式、标注策略开展的系统性试验。例如测试不同正则化规则对实体识别效果的影响比较规则清洗与模型清洗的收益差异。模型训练与超参数调优。通过网格搜索、随机搜索、贝叶斯优化等方式寻找最优参数组合。这本质上是典型的“试验过程”提出假设、设计实验、分析结果、调整参数。推理性能优化。针对 GPU 或 CPU 环境试验模型量化INT8 / FP16、剪枝、知识蒸馏、批处理策略、服务框架选型等。硬件配置和模型结构的不同组合会带来完全不同的性能表现属于典型的技术不确定性。数据管道架构探索。设计可扩展的实时或离线数据处理架构验证分布式训练、数据加载、缓存策略等方案的可行性。评估体系建设。构建包含准确率、召回率、F1、延迟、成本等多维度的自动化评估框架。评估维度如何权衡、如何设计测试集本身就是一个需要实验验证的研发问题。这些活动的共同特征是“探索未知”而不是“执行已知流程”。3.2 难以计入的活动反过来下面这些工作通常不被认定为合格研发直接调用成品模型的 API不做任何自定义修改和微调按照开源项目的文档一步步部署不涉及方案修订和技术验证常规的 Web 前端页面开发、数据库表结构日常维护为了兼容旧版本进行的固定式补丁修改纯非技术性的需求沟通会、项目管理会议、内部协调为生产环境做的例行监控、告警配置、容量规划。这些工作不是不重要而是在做费用归集时应该从研发工时里区分开。如果把大量非研发工时混入申报口径反而会影响整个项目证据链的可信度得不偿失。3.3 边界场景的判断清单实际项目中大量工作处于灰色地带。我的建议是判断标准不取决于岗位名称不取决于项目名里有没有 AI而是取决于这项工作是否为了消除技术不确定性而设计了试验。你可以为项目建立一个简单的问题清单项目启动时我们是否不知道最终技术方案是什么团队是否尝试了至少两种以上的技术路线或参数组合最终决策是否基于实验结果而不是经验猜测实验过程中是否形成了可追溯的版本记录和结果数据任何一个问题的答案是“否”相关工时就要谨慎计入。4. 可计入的费用类型与成本拆分4.1 工资与人力成本研发人员的工资是最大的可计入费用包括研发工程师、算法工程师、数据科学家以及直接参与合格研发活动的技术管理人员的工资和税务成本。这里有一个关键点计入的是“投入到合格研发活动的时间比例”对应的工资而不是岗位全额工资。一个算法工程师既做模型实验又做生产环境维护那么只有用于模型实验的那部分工时对应的工资才能纳入 QRE。这也就是为什么工时记录如此重要——没有工时记录就无法拆分财务只能选择全部排除或按一个模糊比例估算最终结果往往远低于实际应得的抵免金额。4.2 云计算、算力与数据成本在当前的税法框架下云服务费用在满足条件时可以作为合格研发费用的一部分。GPU 训练服务器、模型评测用的推理资源、实验数据存储、对象存储中用于训练集和测试集的数据访问成本都有可能被纳入可计入费用。但需要注意两点只有“用于试验和研发”的那部分算力可以计入。生产环境的推理服务、监控告警、日常运维资源都不属于研发费用。云资源的可追溯性很重要。如果公司所有资源都放在同一个账号下没有任何项目标签财务根本无法区分哪部分是实验消耗、哪部分是生产消耗。这会导致审计时大量费用被剔除。4.3 委托研究与第三方服务如果把部分研发工作外包给高校实验室、独立算法团队、第三方数据标注公司相关费用的 80% 可以作为合同研究费用Contract Research Expense计入。判断依据是外包工作的目的是否是帮助公司完成合格研发活动。同时参与确认和监管的外包工作需要保留技术协议、交付成果、验收记录证明这笔外包支出确实服务于研发目标。4.4 不建议计入的部分办公场地租金、行政管理成本、销售和市场营销费用、业务推广支出这些都不属于合格研发费用。即使项目名义上包含较多算法工作费用归集也必须严格按税法口径执行不能把公司整体运营成本都“摊”进研发费用里。5. 实战建立一套 AI 研发费用追踪体系这是最有工程价值的部分也是很多团队最容易忽略的部分。研发税收抵免的申报不是项目做完之后凭记忆“估算”出来的而是在开发过程中留下足够多的可审计证据。下面从工程视角搭建一套可落地的追踪体系。5.1 第一步项目立项时建立研发标记在项目管理工具Jira、Trello、GitHub Issues 等中为每个任务增加一个自定义字段例如rd_flag取值可以是eligible合格研发活动non_rd非研发活动mixed混合活动部分工时属于研发。建议在团队任务模板里加入一段说明文字这个任务是否涉及技术不确定性的探索 如果是预计的备选方案有哪些如何验证 请在选择完成后将实验结论记录到团队知识库。这样做的目的是在任务创建的时候就完成一次研发性质的初步判断而不是等季度结束再靠回忆补标记。任务标记是后面所有费用归集的起点。5.2 第二步工时记录与实验日志要求核心开发人员按周填写工时拆分粒度到项目或任务级别。同时要有实验日志作为支撑。Git 提交记录是天然的研发活动旁证。下面给出一个 Python 脚本示例用于从 Git 仓库统计每个开发者每日的提交次数作为“研发活动确实发生”的辅助证据import subprocess from collections import defaultdict repo_path /path/to/your/ai-project start_date 2025-01-01 end_date 2025-03-31 cmd [ git, -C, repo_path, log, --since, start_date, --until, end_date, --format%H|%ad|%an, --dateshort ] output subprocess.check_output(cmd, textTrue) records defaultdict(set) for line in output.strip().splitlines(): if not line: continue commit_hash, date, author line.split(|) records[(author, date)].add(commit_hash) for (author, date), commits in sorted(records.items()): print(f{author}\t{date}\t{len(commits)} commits)输出示例zhangsan 2025-01-06 12 commits zhangsan 2025-01-07 9 commits wangwu 2025-01-08 15 commits注意这份统计不是用来直接替代工时表而是作为“该员工确实在这一天从事了代码相关研发活动”的客观佐证。要让工时记录真正可靠建议每周五花 10 分钟填写工时不要拖到月底工时拆分与 Git 活动保持基本一致禁止追溯填写超过 30 天前的记录避免“估算式工时”工时表中的任务 ID 要与项目管理工具中的任务一一对应。5.3 第三步费用归集与技术文档沉淀建议每月整理一次研发费用台账核心字段包括字段说明项目名称与立项记录一致任务 ID对应 Jira/GitHub Issue 编号负责人实际执行人研发工时按小时计人工费用工时 × 工资折算云资源费用按项目标签拆分外包合同金额80% 计入基数关键交付物实验报告、模型文件、评估结果与此同时技术文档的沉淀同样重要。以下文档都可以作为研发活动的支持材料实验方案设计文档评估结果对比表模型或算法选型决策记录Decision Record代码仓库的 tag 和 release notes实验管理平台MLflow、WB 等导出的 run 记录。下面是一个适合 AI 团队的实验记录 Markdown 模板# 实验记录模板 ## 项目名称 文档智能问答系统 ## 实验日期 2025-02-10 ## 要消除的技术不确定性 - 不同 embedding 模型对中文长文检索效果的影响 - RAG 检索 Top-K 参数对答案准确率的影响 ## 实验方案 - 准备 2000 条测试问句覆盖 5 类业务场景 - 对比 bge-large-zh 与 text-embedding-3 的检索效果 - 固定重排模型分别测试 Top-K 3 / 5 / 10 ## 结果与结论 - bge-large-zh 在 F1 上高 4.2%但延迟高 35ms - 选择 Top-K 5 作为生产默认参数 - 完整结论写入 docs/decision-log.md ## 相关代码 - experiments/embedding_compare.py - experiments/retrieval_config.yaml这个模板的价值在于它把“不确定性是什么、怎么试验、结果如何”完整记录下来天然满足研发认定所需的证据要求。同时它也是团队本身需要的工程文档一鱼两吃。5.4 第四步季度复盘与证据归档建议每季度做一次复盘由技术负责人和财务人员一起核验研发工时是否与实际项目进展匹配云资源账单是否按项目正确拆分实验文档是否齐全是否覆盖所有标记为 eligible 的任务新启动的项目是否都完成了研发标记离职员工的未归档文档和代码是否已经沉淀到仓库证据保留周期建议在 5 年以上以应对可能的事后审查。这里特别强调企业应遵循“真实、准确、完整”的原则进行归档不夸大、不虚增每一项数据都应能互相印证。6. 常见问题与排查思路下面整理一些团队在实际操作中最常遇到的问题。问题现象常见原因解决思路财务说“研发费用不达标”工时记录缺失无法拆分建立周工时制度按任务拆分到小时申报时算法工时被剔除没有实验文档无法证明试验过程每周维护实验日志记录假设、方案、结果云账单无法拆分到项目所有资源用同一个账号没有打标签建立云资源命名与标签规范按项目维度拆分Git 记录与工时表不一致开发使用个人分支长期不推送规定每日推送避免批量提交内部使用软件被认定不符合系统只服务内部流程评估业务形态或按更高标准准备创新性证据项目结束后补工时记录记录缺失靠回忆估算禁止事后补录按月沉淀证据外包费用全额计入不理解合同研究费用的规则了解外包费用 80% 计入基数的规则如果你遇到报错或问题可以按下面顺序排查先检查任务标记是否准确是否存在明明做了研发却标记为 non_rd 的情况再核对工时记录是否完整是否覆盖所有 eligible 任务然后检查云资源标签、合同发票是否齐全最后看实验文档和 Git 记录能否互相验证。7. 最佳实践与工程建议7.1 把研发证据融入日常开发流程最理想的状态是研发人员不需要做太多额外工作因为工具链本身就留下了痕迹。建议从以下几个点入手Git 提交信息采用约定式提交feat、fix、experiment、evaluate等前缀让实验类提交一眼可识别实验脚本统一存放在仓库中建立experiments/目录每个实验一个子目录包含脚本、配置和结果云资源强制打标签建立project:xxx、env:train/test/prod、purpose:research/production的标签规范关键决策记录ADR模型选型、架构调整等重大决策在docs/decisions/下记录决策背景和备选方案。这些动作本身就是为了提升工程质量和可复现性和税务申报并不冲突。把它当作“顺手而为”的工程规范而不是“额外的合规负担”团队接受度会高很多。7.2 与财务、税务顾问的协作节奏研发税收抵免不是技术团队单方面能完成的事情。建议建立固定的协作节奏立项时同步研发标记规则让财务知道哪些任务属于合格研发每月同步一次费用台账包括工时汇总和云费用拆分季度例会核对申报范围和工时解决边界争议申报季前由税务顾问提前审阅证据是否充分留出补充时间。这样做的好处是税务顾问不会在最后一刻才发现证据不足而是能在一个持续更新的证据池上工作申报质量和效率都会显著提升。7.3 合规与风险边界最后想强调一下研发税收抵免的申报是基于真实研发活动的权益申请不是财务游戏更不是税收漏洞。以下几点是底线任何团队都应该遵守严禁虚增研发工时或费用严禁为了抵免而伪造实验记录或 Git 提交各项数据必须能够互相印证工时、Git 记录、实验文档、云账单应保持一致对认定有疑问的边界项目主动向税务顾问咨询而不是抱着“先报了再说”的心态涉及多国税务安排时应咨询当地专业顾问确保在合法合规的框架内操作。8. 总结与行动建议梳理一下全文的关键信息定制 AI 开发天然具备大量“消除技术不确定性”的活动与研发税收抵免的认定逻辑高度匹配但不是所有 AI 相关工作都能计入内部使用软件、常规维护、配置性工作通常要排除人工、云计算、委托研究是三类主要可计入费用但需要严格的区分和证据支撑。最终建议很简单每个 AI 团队从今天开始做三件事。第一给正在进行的项目打上研发标记明确哪些任务是 eligible、哪些是 non_rd。第二建立简单的周工时记录规则把工时拆分的粒度从“项目”下沉到“任务”。第三把实验记录模板发给团队成员让每次实验都留下“不确定性—试验过程—结果结论”的完整记录。这些事不需要一步到位先跑起来再逐步完善。研发抵免并不是遥不可及的财务操作它本质上是对“团队正在做的真实技术探索”的一次系统化记录。把这些记录做好了工程资产也更扎实无论是未来申报、融资尽职调查还是技术团队交接都会受益。如果本文对你有帮助可以收藏备用也欢迎在评论区交流你的 AI 项目在研发管理和成本核算上的实践经验。