CCS8.1导入CCS3.3工程：老DSP项目迁移实操指南

接手一个十年前的项目是什么体验？上周同事扔给我一个DSP28335的完整工程，压缩包打开一看，里面全是CCS3.3时代的.pjt工程文件，带DSP/BIOS配置、老版本数学库、一堆绝对路径的头文件引用。老板的要求很直接：代码不能动、功能不能变，但新电脑上要能编译、能烧录、能调试。这里说的CCS8.1导入CCS3.3工程，指的就是把这种历史上用Code Composer Studio 3.3建立的嵌入式DSP项目，迁移到基于Eclipse的新版CCS 8.1环境里重新构建。它不是把文件复制过去就完事——真正要处理的是工程格式、编译工具链、器件支持包和调试链路四个层面的变化。这篇文章是我完整走了一遍之后整理的迁移实操方法，内容包括安装组件怎么选、导入有哪些坑、编译器版本差异会造成什么错误、DSP/BIOS工程怎么处理，以及最后怎么把程序在目标板上跑通。给正在被老DSP工程折磨的人一个尽量少走弯路的参考。

1. 为什么CCS3.3工程必须迁移：不是"导入"而是"重建"

1.1 CCS3.3工程的现状与历史包袱

CCS3.3是TI在2006到2008年前后主推的经典IDE版本，也是最后一代非Eclipse内核的图形界面。那个年代国产自动化设备、电力电子装置、音频处理板卡大量使用TMS320F2812、TMS320F28335、TMS320C6713、DM642这些芯片。很多设备现在还在产线上一台一台地跑，但控制器的源代码还留在老工程师的电脑里，工程文件后缀是.pjt，编译选项存在工程的Build Options里，调试器普遍是并口XDS510或者USB XDS510。

最大的痛点是环境本身。CCS3.3是32位Windows程序，官方支持Windows 2000/XP，在Win7上已经有不少兼容性问题，到Win10/11的64位系统上基本装不上、装上也跑不稳。而认证、审计、备件恢复这些需求偏偏要求能在新机器上把这个老工程重新编译出同一个.out文件。IT部门不可能为了一个IDE给你留一台WinXP工控机常年开机，所以迁移到新版本CCS是唯一现实出路。

1.2 两个版本IDE之间的技术断层

很多人误以为"导入"就是把老工程路径加进新IDE列表。真正的情况是：从CCS4开始，TI把整个IDE底座换成了Eclipse框架，工程描述从.pjt改成了.projectspec、.project、.cproject这套XML体系。CCS8.1本身已经完全没有加载.pjt的逻辑，它只能通过一个专门的"Legacy CCS 3.3 Project"导入器去解析.pjt，再把里面的源文件列表、编译选项、链接选项翻译成新版格式。

同时，编译器工具链也换代了。CCS3.3里C2000的CGT（Code Generation Tools）通常是v4.1.x，C6000是v6.0/v6.1；CCS8.1自带的是C2000 CGT v16.9.x、C6000 CGT v8.x。编译器版本跨越这么大，老代码里的一些关键字、内联函数、优化行为都会有差异。器件支持数据库也变了，CCS8.1对老型号芯片的支持被归到"Legacy"组件里，安装时没勾选，后面连器件型号都可能认不出，更别说编译了。

两个版本的关键差异我列了个表，这个表基本决定了整个迁移的工作量：

所以看明白了吗？迁移的本质是把.pjt里记录的构建意图，翻译成新版IDE能理解的一套独立工程配置。翻译过程会有信息损耗，这就是后面所有坑的根源。

2. 环境准备：CCS8.1组件安装直接影响导入成败

2.1 下载与安装时点选哪些组件

先把CCS8.1拿到手。TI官网需要注册myTI账户，下载页面提供在线安装器和离线安装包，强烈建议直接下载离线完整安装包。因为这个工具链体积大，在线安装一旦断网或代理出问题就得重来。离线包大概好几个GB，提前下好。

安装过程本身不复杂，但"Select Components"这一步非常关键。这里有你要用的处理器家族，比如C2000、C6000、MSP430、ARM，展开后能勾选具体器件系列。务必把目标芯片的家族选上，同时在这个页面里找到带"Legacy"字样的组件并勾上。Legacy组件包含老器件支持包和老版本编译器，CCS3.3的F28335、C6713这类芯片就靠这个才能在CCS8.1里被识别。如果安装时漏了，导入向导能勉强把.pjt读进来，但工程属性里工具链会显示成"unresolved"，构建直接中断。

还有一个容易忽略的是XDCtools。如果你的老工程将来要往SYS/BIOS迁移，或者新版里要用到一些基于XDC的组件，这个必须一并勾选。另外还有各类浮点数学库、图像库，按需选择，不必图多。

2.2 安装完成后如何补装组件

装完了发现组件漏了也有救。CCS8.1的菜单里找到Help > Install System Components，打开后是同样的组件选择界面，可以在现有安装基础上追加勾选。实际操作中这个功能对网络要求较高，如果公司内网有代理限制，加载组件列表可能会卡住。我碰到过一次列表始终转圈的情况，最后是把CCS完全卸掉重装，一次性把组件勾全才解决的。

更灵活的办法是去TI官网的软件存档页单独下载对应版本的Legacy Compiler，装好后在CCS的Project Properties > Build > General里手动指认工具链路径。这个方法适合只需要某一个特定编译器版本、不想要整套组件的情况，但步骤多、容易配错，不如一开始就勾Legacy省事。

2.3 迁移前在旧环境下必须做的事

如果公司里还有一台能跑CCS3.3的老机器，先别急着做迁移。开机，打开老工程，执行一次Clean + Rebuild，确认工程在旧环境下是能完整编译通过的。这个动作能排除"工程本来就有问题"的干扰，给迁移后的排错一个明确基线。

然后在旧环境里记下这几样东西：

• 编译器精确版本：Help > About里能看到，例如TMS320C28xx CGT v4.1.2。
• 工程使用的目标器件型号。
• 编译器选项：优化级别、内存模型（small/large）、是否生成汇编列表文件。
• 预处理符号列表，比如常见的_DEBUG、DSP28_ADC这些。
• 链接器选项：库搜索路径、库文件名、CMD文件路径。
• 老工程生成的.map文件，留做迁移后对照内存分配。

这些信息有些在.pjt里记录得不完整，导入器不一定能原样翻译。我之前吃过一个亏：老工程用的是大内存模型编译，.pjt里记录了-lm标志，但导入后工程属性的编译选项里对应的内存模型设置没有正确映射，结果程序一跑就花屏。所以迁移前记录基线不是形式主义，是真能救命的。

3. 导入工程：两条路径和导入背后的映射逻辑

3.1 用Legacy导入向导处理.pjt

拿到干净、可构建的老工程副本之后，进入CCS8.1先建一个专门的workspace，别把导入的老工程塞到其他项目混杂的workspace里。

标准入口是File > Import > Code Composer Studio > Legacy CCS 3.3 Project(s)。在弹出的对话框里选择.pjt文件，也可以直接选.pjt所在的整个目录，导入器会自动扫描识别。如果你用的是CCS8.1里更常见的Project > Import CCS Eclipse Projects，也能识别.pjt，但那个入口主要面向新格式工程，对老工程的处理不如Legacy向导完整。

点击Finish后，导入器会解析.pjt，在Project Explorer里生成一个同名的Eclipse工程，并额外生成一个描述导入关系的.projectspec文件。这里要注意：原始.pjt文件不会被修改，但工程目录里会多出几个新文件，这是正常现象。导入前务必备份一份完整工程，包括Debug目录和所有.cmd、.cdb，这个动作不能省——我见过导入器在解析某些特殊字符路径时直接崩溃，把工程目录搞乱的案例，虽然概率低，但老工程通常没有版本管理，丢了就是灾难。

3.2 导入时工具会迁移哪些设置

理解导入器到底做了什么，后面排错才有方向。正常情况下，导入器会把以下几类信息翻译成新版Format：

• 工程里的源文件列表和文件夹结构
• 编译器的包含路径、预处理宏定义
• 优化级别、调试信息选项、内存模型、字节序
• 链接器的库搜索路径和显式链接的库文件
• 输出文件名和输出类型（可执行文件/库）
• 老工程里定义的Build Configurations，如Debug、Release

但有几类东西它不会替你处理：

• 绝对路径引用。老工程师喜欢在包含路径里写C:\tidcs\c28\DSP2833x\include这种盘符路径，导入器原样搬过来，而目标机器上根本没这个目录。
• 老版本编译器选项的精确映射。.pjt里的某些开关在新版CGT里改了名字甚至删除了，导入器只能尽力匹配，匹配不到就丢。
• 环境变量。老工程的构建过程可能依赖TI的系统环境变量，新环境没有。
• DSP/BIOS的语义。.cdb文件本身会被保留和引用，但新版IDE对DSP/BIOS配置工具的集成方式和CCS3.3完全不同。
• 仿真器目标配置。这部分确定要重新建。

3.3 导入完成后第一轮检查

导入完成先别急着点Build，按这个清单过一遍，能省掉后面大量无头绪的报错：

1. 确认Project Properties > General里的器件型号和导入前记录的一致。
2. 检查Output Format，是COFF还是EABI（ELF），这决定了后面的库和入口符号。
3. 确认编译器版本是预期值，如果显示缺失，回到第2章补装。
4. 打开Compiler > Include Options，把那些绝对路径改成相对路径或新环境实际路径。
5. 检查Compiler > Predefined Symbols，老工程定义的宏有没有全部保留。
6. 打开Linker > File Search Path，看库搜索路径和库文件名是否合理。
7. 确认.cmd链接命令文件仍然在工程里，且路径正确。
8. 看一眼Problems视图，导入器有时会以warning形式提示哪些选项无法翻译。

第一轮检查往往能发现一半以上的问题。不要跳过，回头再翻工更浪费时间。

4. 重建编译环境：编译器、头文件与运行库的对齐

4.1 选定CGT版本：尽量贴近原版还是直接用新版

导入成功的工程，构建时用的是哪个版本的编译器，完全取决于工具链配置。这里我推荐一个稳妥路径：第一次构建优先选择和老板本接近的Legacy CGT，让工程先跑通，再逐步升级编译器版本。

原因在于老代码是为老编译器写的。C2000 CGT v4.x和v16.x之间，编译器对C89/C99的处理、内联函数的支持范围、汇编器语法都有差异。一步跨到最新版，报错可能几十条起步，你分不清到底是工程配置问题还是代码本身与新版编译器不兼容。用老版本编译器先构建通过，等于先把工程格式的变量排除掉，再单独面对编译器升级的问题，排错维度一下子清晰了。

CCS8.1里一个工程可以随时在Properties > Build > General里切换工具链版本，装的多个CGT之间互不影响。实测下来，同一个F28335工程，老CGT v6.4和新CGT v16.9各自都能编译，但优化后的浮点运算结果存在微小差异，这对于做电机控制、逆变器算法的项目是必须警惕的。

4.2 头文件路径的整理思路

老DSP工程很少有把全部依赖放进工程目录的习惯，更多的是引用TI官方例程包或公司共享代码库。CCS3.3时代最常见的路径结构是C:\tidcs\c28\DSP2833x\include这种，这个"tidcs"目录是当年CCS安装时捎带装进去的芯片支持库。迁移到新机器后，这个目录根本不存在。

我的做法是把所有外部依赖统一拷贝到工程目录下的libs或Libraries子目录里。比如DSP2833x_headers、DSP2833x_common、IQmath、以及公司自研的公共模块，全部平铺进去。然后在Include Options里全部改成相对路径，比如${PROJECT_LOC}/libs/DSP2833x_headers/include。这样工程整体可以随文件夹移动，换电脑、交给同事都不用重新配路径。

相对路径里这个${PROJECT_LOC}是Eclipse内置变量，表示工程根目录。如果工程里嵌套了多个子工程，还有${ProjName}等变量可用，用这些变量写路径比写死"..\..\"要稳得多。

4.3 COFF与ELF（ABI）的抉择

这是整个迁移里最容易翻车、也最不容易被理解的一环。CCS3.3时代链接输出基本全是COFF格式，目标文件后缀.obj、库文件后缀.lib、最终输出.out。而新版CGT的默认ABI已经切到了ELF/EABI，对C2000和C6000编译器来说，默认生成的.obj、.a库、输出文件都是EABI规范。

这里的关键原则是：同一个可执行文件内，所有目标文件和库文件的ABI必须一致。老工程里如果有别人提供的预编译.obj库，或从网上下载的二进制库，而这些库是COFF格式，你新工程就算所有源码都能编译，链接阶段也会报一堆"unresolved symbol"或"object file has incompatible format"错误。

处理思路只有两条：要么整个工程坚持COFF（在新版CGT里通过--abi=coffabi显式指定），让老库能继续用；要么全面切到EABI，把所有源码重新编译，同时找到对应EABI版本的库。对于那种所有源码都在手里、没有外部二进制依赖的工程，直接切EABI更干净；反之，有老库又拿不到EABI版本的，就得维持COFF。

切到EABI还会引发一个连锁问题：入口符号和命名规则变化。COFF模式下C语言函数名在汇编层面带下划线前缀，EABI下符号命名规则变了。老工程的.cmd链接命令文件里如果硬编码了--entry_point=_c_int00这类入口，在EABI下会报"entry point symbol not found"。处理方法是把入口指定删掉，让工具链按默认入口走，或者在.cmd里改成新规范对应的入口符号名。

4.4 运行库文件名的坑

链接器搜索路径和库文件名是另一个高发地。老工程里经常直接写-rts2800_ml.lib这种库名，新版CGT的库文件命名在某些ABI下会变化。我用表格列一下常见对应关系，方便对照：

库文件名一旦对不上，链接器要么直接提示找不到文件，要么在连接时静默跳过导致大量未解析符号。检查链接日志时，优先确认实际参与链接的库文件路径是哪个，别凭记忆猜。另外，如果你的工程用了IQmath这种专用数学库，同样的ABI问题也会发生：CCS3.3下是IQmath.lib，新版EABI环境是IQmath_eabi.lib，这类库的替换比运行库更隐蔽，因为它在cmd里可能被写成完整路径。

5. 实测踩坑：导入后最常见的五类报错与完整排查链路

5.1 器件型号不被识别

症状是导入成功了，但工程属性里器件型号是空的，或者在构建时直接报"device type is not recognized"。打开Problems视图看到这类错误，先别怀疑工程，回来的方向一定是CCS安装缺少对应的器件支持。

排查链路：Tools > Device Management或Properties > General里看器件列表里有没有这个型号。如果列表里没有，回到Help > Install System Components，在对应的处理器家族下找到Legacy Device Support并安装。还有一种情况是型号太老，新版本器件数据库里彻底移除了。比如TMS320C6211这个型号在新CCS里就不好找，处理办法是在同一个家族的Generic项里选一个相近型号，然后在代码层面通过头文件重新指定，这需要一定的移植工作量。

5.2 头文件找不到：cannot open source file "DSP2833x_Device.h"

这是我见过出现频率最高的错误。老工程的Include Options里通常是一串绝对路径，比如C:\tidcs\c28\DSP2833x\include，导入器把这些路径原封不动搬了过来，新机器上自然找不到。

排查链路：在Problems视图双击报错条目，定位到具体.c文件，右键工程属性打开Compiler > Include Options，对照第4.2节的思路把路径改成工程内实际位置。特别注意#include指令有两种写法，尖括号<>按Include Options路径搜索，双引号""先搜索当前源文件目录再走Include Options。老工程里混用这两种写法很常见，路径配置时要把两类都覆盖到。

这里有个容易被忽略的细节：如果代码里引用的头文件在某个子目录下，而工程属性里只配了子目录的上级目录，编译器是搜索不到的，必须把路径精确到头文件所在的那一层。我吃过这个亏：以为配置了DSP2833x_headers目录就够了，结果该目录下还有include子目录，头文件实际在include里面，白折腾了半小时。

5.3 链接器报 unresolved symbol 和入口问题

链接阶段报"undefined symbol"要分两类看。一类是工程代码自身的函数未定义，那是源码问题；另一类是最常见的：入口符号和运行库缺失。

排查链路：打开构建日志，找到"undefined symbol"后面的符号名。如果看到_c_int00或者类似带c_int00的符号，说明boot入口没找到。这时候去Linker > Basic Options或.cmd里看有没有显式指定--entry_point，有就按第4.3节处理，没有就检查运行库是否参与链接。如果报的是memcpy、strcpy这类标准库函数未定义，基本可以断定运行库没进去，回到第4.4节检查库文件名和搜索路径。

还有一种隐蔽情况：老工程链接了一个公司自己封装的预编译库，比如control.lib，它是COFF格式，而新工程切成EABI后导致ABI不匹配。这种在构建日志里通常有格式不兼容的警告，如果不仔细看日志，光看"unresolved symbol"会误判成自己的代码问题，实际上换个EABI版本的库就好了。

5.4 编译通过了但运行结果和老版本不一致

这是最让人头大的一类问题。没有报错，链接成功，烧进板子也能跑，但某个控制量的输出跟老机器上跑的对不上，或者某段状态机的时序乱了。原因基本锁定在编译器优化行为差异上。

CGT v4.x和v16.x对浮点运算、循环展开、数据对齐的处理策略差别很大。老编译器生成的代码可能依赖了特定中间精度，新编译器在-FP-reassoc、-O2级别下对运算顺序做了重排，结果就变了。这种问题没有银弹，只能一步步定位。

我的做法是：先在工程属性里把优化级别降到-O0，确认逻辑行为正常，然后逐步提升优化级别，每级跑一遍相同用例，找到行为突变的优化开关，再针对出问题的函数使用#pragma优化控制，比如#pragma FUNC_NEVER_INLINE、#pragma CODE_SECTION，把关键函数单独指定到保守优化级别。如果项目对位一致要求极高，最稳妥的选择还是直接把编译器锁定到与老版本接近的Legacy CGT版本。

5.5 老语法与新CGT的警告大爆发

换到新版编译器后，同一份代码编译产生的警告数量可能增加几十倍。有的是C89标准到C99/C11的变化，比如隐式函数声明、隐式整数转换；有的是新编译器对"interrupt"关键字、far/near指针处理的差异。

面对海量警告，我的经验是先不要在第一时间追求"零警告"。先把警告分成两类：一类改动会改变程序行为，比如符号重定义、隐式转换可能引起精度损失；另一类纯粹是格式和风格问题。第一类必须改，第二类用编译选项将对应警告降级为info或者先放着，等程序在目标板上验证通过后再回头清理。

千万别做的是在Build选项里直接勾"Treat warnings as errors"，这样会让原本能用的代码在新工具链下彻底编不过去，自己给自己添堵。

6. DSP/BIOS老工程的特别处理

6.1 .cdb在CCS8.1中还能不能编

老工程里如果带了DSP/BIOS，工程文件里一定有个.cdb配置文件。这个文件是DSP/BIOS配置工具的产物，构建时自动生成对应的cfg_c.c、cfg.h和一段链接命令，然后跟应用代码一起编译链接。

在CCS8.1里，.cdb文件本身还是能被识别的，前提是CCS里装了DSP/BIOS 5.x产品。如果安装组件时选了Legacy，通常DSP/BIOS 5.x也在其中。构建时，如果.cdb没有被正确处理，会看到类似"cannot run DSP/BIOS config tool"这类错误，或者生成的cfg_c.c文件根本没有出现。

先确认工程属性里DSP/BIOS产品有没有正确关联。如果关联不上，可以手动把老工程里由.cdb生成的那些cfg文件（而不是.cdb本身）直接加入构建，相当于绕过配置工具，直接用上一次生成的配置代码编译。这个办法适合DSP/BIOS配置很久没动过、完全不需要改的工程，能绕开一整套工具链兼容问题。

6.2 迁移到SYS/BIOS的决定因素

如果业务要求DSP/BIOS配置必须能修改，那就得考虑迁移到SYS/BIOS，新环境对SYS/BIOS的支持是正常的。这个判断要务实，我列几个考量因素：

• 老代码对DSP/BIOS的API依赖有多深。只用HWI、SWI、SEM、LOG这几个模块，迁移成本低；用了PIP、DIO、自研设备驱动插入DSP/BIOS的，成本翻倍。
• 产品是否需要长期维护。如果只是生产几台老产品收尾交付，用第6.1节的静态方案更省事；如果还要五年十年的维护期，长痛不如短痛，迁到SYS/BIOS反而划算。
• 团队对新RTOS的熟悉程度。SYS/BIOS的配置基于XDCtools的.cfg文件，完全是另一种工作流，团队没有经验的话，迁移成本里还得算上学习时间。

SYS/BIOS迁移路径是：在导入后的工程里新建一个.cfg，把DSP/BIOS里的模块对应移植过来，HWI对应Hwi、SWI对应Swi、TSK对应Task、SEM对应Semaphore、MBX对应Mailbox、LOG对应Log。应用层只要没直接操作DSP/BIOS的数据结构，大部分C代码可以原样保留。链接命令文件要重写，因为SYS/BIOS的内存段管理和DSP/BIOS不同。

6.3 完全去掉RTOS的降级方案

还有一类非常简单的老工程，其实只是借用了DSP/BIOS的定时器和信号量，根本没有多任务。这种工程我建议直接去掉RTOS，改用裸机方式：把TSK主循环改成while(1)大循环，把HWI中断对应改成普通ISR写进中断向量表，把SWI软件中断改成定时器中断里置标志、主循环里查标志。这个方案完全不依赖RTOS产品，可移植性最好，调试也最直观。

去掉RTOS之后，记得把.cdb从工程构建里移除，同时把原来DSP/BIOS生成的链接命令片段移除，在.cmd里重新划分内存段，把原来预留给RTOS任务栈和内核堆的RAM释放给应用使用。这一步要参照老工程.map文件里的内存占用情况，避免把还在用的缓冲区覆盖掉。

7. 调试链路重建：目标配置、仿真器与烧写验证

7.1 新建Target Configuration（.ccxml）

程序编译出.out只是第一步，能下载到板子上调试才算整个迁移完成。CCS8.1里的调试链路通过Target Configuration文件（.ccxml）管理，CCS3.3时代那种直接在IDE里选板卡的方式已经没了。

新建方法：File > New > Target Configuration File，输入名称后，在Connection框里选择实际使用的仿真器，比如Texas Instruments XDS110 USB Debug Probe、XDS100v3或XDS510 USB；在Device框里选择目标芯片，保存后得到.ccxml文件。右键这个文件，选择Launch Selected Configuration，弹出的调试会话里就能加载.out了。

有一点要提前说：这个.ccxml文件建议按板卡而不是按工程来建，多块相同板卡复用一个配置，避免每导入一个工程就重新配一次仿真器。

7.2 老仿真器的驱动问题

CCS3.3年代最普及的仿真器是XDS510，分并口和USB两种。CCS8.1里并口XDS510已经没有驱动支持了，USB XDS510在Win10 64位下还算能用，但需安装对应厂商的驱动，且Win10后续系统的驱动签名要求可能让老驱动安装失败。如果手头只有并口XDS510，那我们能做的选择很有限：要么找一台老Windows机器专门跑，要么直接换XDS110或XDS100v3仿真器。

XDS110是现在TI的默认选择，USB接口，CCS8.1内置驱动，即插即用。如果公司预算允许，迁移老工程的同时换一个XDS110，调试链路的可靠性会高很多。这钱不该省——拿并口XDS510在半夜调试时突然蓝屏的滋味，谁试谁知道。

7.3 烧写与回读验证

调试链路通了之后，别急着把整个.out烧进Flash，先做RAM加载验证。把编译好的.out加载到DSP的RAM里运行，观察几个关键寄存器和全局变量，确认CPU能跑起来、定时器中断能触发。这个步骤能快速排查目标配置和工程设置层面的根本错误。

RAM验证通过后再烧Flash。CCS8.1里C2000和C6000的Flash烧写方式略有不同，但大原则一致：先在工程属性里配置Flash编程器和烧写地址，或通过调试会话里的Program Load菜单调用on-chip Flash API。烧写前注意三点：关闭看门狗、正确配置时钟、做好整片擦除或扇区擦除的选择。烧完复位运行，用串口或网口输出对比老程序的行为，最好连ADC采样值、PWM占空比波形也一并核对。

写在最后的实操体会

这次迁移前后折腾了一个星期，最深刻的感受是：CCS8.1导入CCS3.3工程，工具只帮你完成了20%的工作，剩下80%是工程配置重建、头文件路径整理、ABI取舍、运行库匹配这些脏活。别指望导入器一键全自动，也别在导入失败时反复重试同一路径，要按工程格式、编译器、器件支持、调试配置四个层次逐个击破。

还有个小技巧分享给你：迁移完成、程序稳定运行后，把新版工程里修改过的.projectspec文件提交到版本管理，同时把整个工程目录连同依赖库打包一次。这个快照就是下次任何人接手时的起点，再把迁移过程中记录的CGT版本、ABI选择、库对应关系写进README，基本能把这次踩坑的经验完整传下去。毕竟这种老工程五年后可能又要换一台新电脑重新来一遍，留好文档就是救未来的自己。