1. 会计信息管理系统作为毕设选题为什么我建议你做这个先说个真实场景。每年三四月份我都能在技术群里看到一批被毕业设计折磨的学生选题太偏没人做过参考资料少得可怜选题太泛做着做着发现根本没边界还有一类更惨选题做完了但自己的代码根本讲不清楚到了答辩现场被老师连问三个问题就卡壳。会计信息管理系统恰好是那种看上去传统、实际含金量不低、参考资源和源码都比较充足的毕设方向。它不是蹭区块链、人工智能这种热度但它的业务逻辑非常明确凭证录入、账簿登记、报表输出这些是会计工作的核心链路放到系统里就是清晰的模块边界。你不需要去编造需求会计这门学科已经把规则定死了——有借必有贷借贷必相等。这条准则本身就是天然的校验逻辑能让你在设计系统时少走很多弯路。选这个题做毕业设计另一个隐形优势是面试有故事可讲。财务数字化、业财一体化在企业里是真实存在且持续投入的方向哪怕你不是去面财务软件开发岗你在介绍项目时提到我设计了一个科目余额表的自动汇总逻辑处理了跨期凭证的结转问题这种切切实实的业务落地能力远比我写了个增删改查有说服力。这篇文章我就把我自己带学生做这套系统时的一些思路、设计取舍、核心代码和踩坑经历完整拆开来讲。适合正在选毕设题目的同学也适合那些已经选了类似系统、但不知道该怎么把东西做出来变成逻辑讲清楚的人。内容围绕源码实现来讲——所有代码思路、表结构、接口设计都是能直接落到你自己的项目里的。2. 需求不该靠猜从会计业务规则反推系统模块很多同学做管理系统容易犯一个毛病先去画用例图、画ER图但问起这个字段为什么必须有这个流程为什么这样走答不上来。这样写到论文里评审老师一眼就看出来是拼凑的。正确的做法是先理解业务本身再让技术服务于业务。2.1 会计工作的核心流程决定了系统的主干会计日常做的是这么几件事根据原始凭证填制记账凭证审核通过后登记总账和明细账期末做结转最后输出试算平衡表、资产负债表、利润表。这几件事映射成系统模块就是基础数据管理会计科目、辅助核算项客户、供应商、部门、期初余额凭证管理录入、审核、过账、作废、查询账簿管理总账、明细账、日记账的查询展示期末处理结转损益、结账报表管理科目余额表、试算平衡表、利润表这么拆分完系统的边界就非常清楚了。不会出现我该不该做一个固定资产模块这种纠结——核心链路之外的功能毕设阶段一律先砍掉除非你的题目明确包含。2.2 借贷记账法是如何变成系统校验规则的会计里最基础的原则每一笔分录至少涉及两个科目借方金额合计必须等于贷方金额合计。这个规则在系统里直接转化为保存凭证时的硬校验。换句话说你的Service层根本不存在只录入借没有贷的可能性。另外还有一个规则容易被忽略——科目余额方向。资产类科目余额在借方负债类、权益类科目余额在贷方损益类科目期末要结转清零。系统在做余额汇总时需要根据科目的余额方向决定是加还是减。如果表设计里没有余额方向这个字段你后续算资产负债表的期末数时就会很难受只能靠硬编码匹配科目编码前缀那种写法后期维护起来想哭。2.3 用例视角三种角色就够用了别贪多毕业设计的系统权限没必要做成复杂的RBAC权限引擎一般三种角色足够角色核心职责典型操作系统管理员基础数据维护、用户管理科目维护、角色授权、数据备份会计日常业务处理凭证录入、凭证审核、账簿查询管理员/财务主管审核、报表、结账凭证审核、期末结转、报表查看三种角色背后是两层的权限控制菜单/按钮级别的功能权限谁能看到什么页面、能点哪个按钮以及数据范围的控制比如会计只能看到自己录入的凭证主管可以看到全部。后者很多毕设会忽略但答辩时如果老师问你的系统怎么防止张三会计篡改李四会计做的账这就是一个很好的加分点。2.4 功能清单阶段性规划按一个学期的正常节奏建议把开发分成三个阶段第一阶段做基础数据和凭证这是心脏第二阶段做账簿和报表这是发动机第三阶段做系统管理和期末处理这是配套。千万别一上来就想着把界面做得多花哨会计系统最重要的是功能闭环——凭证录进去能查到账账能汇总成表表能对上数这一条链子通了项目就立住了。3. 技术选型的取舍不用最潮的用最稳的技术栈直接决定你写代码的效率和论文里可以吹的内容。我的建议是业务系统类的毕设不要玩花活。3.1 后端Spring Boot MyBatis Plus 是稳妥组合现在市面上能看到的会计信息管理系统毕设源码绝大多数基于Spring Boot这本身就是一种市场筛选。Spring Boot的好处不用多说自动配置、内嵌Tomcat、生态成熟遇到问题搜一下几乎都有答案。ORM层面的选择有人用JPA有人用MyBatis我的建议是MyBatis Plus。理由很实际会计系统的查询条件特别多凭证按日期范围、按科目、按摘要模糊查询、按金额区间组合筛选用MyBatis Plus的LambdaQueryWrapper可以非常流畅地拼条件不用写大量的XML映射文件。而且它对分页的支持也省事打印凭证列表这种场景一行代码搞定。如果你在参考源码时看到基于Spring MVCJSP的老项目不是不能用但有三个现实问题第一前端页面和Java代码耦合在一起改UI就要重启项目第二答辩演示时老项目的界面观感差一截第三面试时候问你用过前后端分离吗你只能摇头。所以尽量选前后端分离的方案哪怕Vue你只学了基础做个登录页加列表页撑住主界面问题也不大。3.2 前端Vue 2还是Vue 3以及那些UI库Vue 3确实已经是主流但Vue 2 Element UI的存量项目和参考源码更多。如果你是零基础或半吊子水平我建议直接Vue 3 Element Plus别犹豫。原因就一条现在新写的教程、遇到bug搜到的解决方案Vue 3的占比已经碾压Vue 2。页面不用多六到八个核心页面就够登录页、系统首页放点统计卡片、科目管理页、凭证录入页、凭证列表页带审核操作、账簿查询页、报表页、用户管理页。这些页面用Element Plus的表格、表单、日期选择器、对话框组件基本上就能拼出来不用自己造轮子。3.3 数据库MySQL 8.x表结构和索引要注意MySQL 8.x相比5.7在窗口函数、通用表达式CTE上做了增强这对做财务报表类的汇总查询很有帮助后面讲到报表SQL时会再说。表结构设计我按五个核心表来拆科目表、凭证表、凭证明细表、用户表、角色表。它们之间的关系是一个凭证包含多条明细每条明细对应一个科目一个用户拥有一种角色。期初余额的处理很多人会搞错。我建议单独建一张科目期初余额表字段包括科目ID、年份、期间、借方期初、贷方期初。这样期末结账的时候每个期间的期初数是从上一期的期末结转过来的逻辑会非常清楚。3.4 为什么不用那些看起来更高级的技术我在某些毕设源码网站上见过给会计系统上微服务、上Redis缓存、上RabbitMQ消息队列的方案我强烈建议你别学。原因不是这些技术不好而是你的业务规模撑不起这套架构一个学校的毕设系统并发量可能还没你朋友圈点赞量大引入分布式组件只会增加部署复杂度和你答辩时讲不清的风险。用个Spring Cache或者干脆不加缓存项目一样跑得飞起。记住一句话架构是为业务服务的不是用来凑字数的。4. 数据库设计五个核心表加一个关联表足够了数据库设计是整个系统的地基。我见过太多毕设源码的数据库表设计得很漂亮但做出来的系统根本没法用——不是字段缺了就是冗余得一塌糊涂。下面是我推荐的建表方案直接可以拿来改。4.1 科目表和凭证表核心中的核心科目表的设计逻辑是这样的CREATE TABLE account_subject ( id BIGINT NOT NULL AUTO_INCREMENT, subject_code VARCHAR(20) NOT NULL COMMENT 科目编码如1001库存现金, subject_name VARCHAR(50) NOT NULL COMMENT 科目名称, parent_id BIGINT DEFAULT NULL COMMENT 父级科目ID实现层级, subject_type TINYINT NOT NULL COMMENT 1资产 2负债 3权益 4成本 5损益, balance_direction TINYINT NOT NULL COMMENT 余额方向 1借方 2贷方, is_deleted TINYINT DEFAULT 0, create_time DATETIME DEFAULT NULL, PRIMARY KEY (id), UNIQUE KEY uk_subject_code (subject_code) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT会计科目表;科目编码的设计要遵循会计制度习惯1001开头的是一级科目100101是二级科目。很多系统不考虑层级关系把科目名称做成一个扁平的字符串等你做上级科目汇总下级科目余额的功能时就会非常痛苦。凭证主表和明细表是典型的一对多必须分开建。CREATE TABLE voucher ( id BIGINT NOT NULL AUTO_INCREMENT, voucher_no VARCHAR(20) NOT NULL COMMENT 凭证号如记-0001, voucher_date DATE NOT NULL COMMENT 凭证日期, attachment_num INT DEFAULT 0 COMMENT 附件张数, status TINYINT DEFAULT 0 COMMENT 状态 0草稿 1已审核 2已过账 3已作废, create_by BIGINT DEFAULT NULL COMMENT 制单人, create_time DATETIME DEFAULT NULL, audit_by BIGINT DEFAULT NULL COMMENT 审核人, audit_time DATETIME DEFAULT NULL, PRIMARY KEY (id), UNIQUE KEY uk_voucher_no (voucher_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT记账凭证主表; CREATE TABLE voucher_entry ( id BIGINT NOT NULL AUTO_INCREMENT, voucher_id BIGINT NOT NULL COMMENT 凭证主表ID, entry_index TINYINT NOT NULL COMMENT 分录序号, subject_id BIGINT NOT NULL COMMENT 科目ID, direction TINYINT NOT NULL COMMENT 方向 1借 2贷, amount DECIMAL(15,2) NOT NULL COMMENT 金额, summary VARCHAR(200) DEFAULT NULL COMMENT 摘要, PRIMARY KEY (id), KEY idx_voucher_id (voucher_id), KEY idx_subject_id (subject_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT凭证明细表;这里关键一点金额字段必须用DECIMAL(15,2)绝对不能用float或double。这是会计系统的红线等我在第五章展开讲为什么。4.2 总账表用来加速查询的存在理论上有了凭证表就能通过SQL实时汇总出任何科目的发生额和余额。但当数据量大了以后——比如一个模拟公司的账套有几千条凭证——实时汇总的查询会越来越慢。所以正规一点的会计软件会有一个总账表定期从凭证表汇总数据到总账表。CREATE TABLE general_ledger ( id BIGINT NOT NULL AUTO_INCREMENT, subject_id BIGINT NOT NULL, period VARCHAR(7) NOT NULL COMMENT 会计期间如2025-05, debit_total DECIMAL(15,2) DEFAULT 0 COMMENT 本期借方发生额, credit_total DECIMAL(15,2) DEFAULT 0 COMMENT 本期贷方发生额, opening_balance DECIMAL(15,2) DEFAULT 0 COMMENT 期初余额, closing_balance DECIMAL(15,2) DEFAULT 0 COMMENT 期末余额, PRIMARY KEY (id), UNIQUE KEY uk_subject_period (subject_id, period) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT总账汇总表;期末结账的时候程序按期间把所有未过账的凭证汇总进总账表同时把上期的期末余额转到这期的期初余额。这样做的好处是查询账簿变成纯查表的操作速度极快。4.3 用户、角色及一个容易忽略的辅助核算表用户表和角色表属于常规设计这里不展开。我要提醒的是一个在答辩时特别加分的点——辅助核算。现实中企业记账除了要知道记在哪个科目上还经常要知道这笔账对应哪个客户、哪个供应商、哪个部门。比如应收账款——甲公司和应收账款——乙公司在系统里如果作为两个科目来建科目表会爆炸。正确的做法是科目表里只有应收账款科目再通过一张辅助核算表记录是哪个客户的CREATE TABLE auxiliary_item ( id BIGINT NOT NULL AUTO_INCREMENT, entry_id BIGINT NOT NULL COMMENT 凭证明细ID, item_type VARCHAR(20) NOT NULL COMMENT 客商/部门/项目, item_name VARCHAR(100) NOT NULL COMMENT 具体名称 );加了这张表你可以做一个应收账款按客户维度汇总的统计页面这在答辩演示时是一个很出彩的功能点而且工作量并不大。5. 核心功能实现凭证、过账、报表的代码思路这一部分直接上可落地的实现思路和代码骨架。每一个环节我都尽量解释这样写的业务理由。5.1 凭证保存时事务和校验缺一不可凭证保存是整个系统里最需要细心处理的接口。我在设计这个Service时代码的核心逻辑分四步走第一校验明细的借贷平衡第二校验每个明细科目ID是否有效第三生成凭证单号第四主表和明细表一起落库整个过程必须在一个事务里。代码如下Service public class VoucherServiceImpl extends ServiceImplVoucherMapper, Voucher { Autowired private VoucherEntryMapper voucherEntryMapper; Override Transactional(rollbackFor Exception.class) public boolean saveVoucher(VoucherDTO dto) { // 1. 校验借贷平衡 BigDecimal debitSum dto.getEntries().stream() .filter(e - e.getDirection() 1) .map(VoucherEntryDTO::getAmount) .reduce(BigDecimal.ZERO, BigDecimal::add); BigDecimal creditSum dto.getEntries().stream() .filter(e - e.getDirection() 2) .map(VoucherEntryDTO::getAmount) .reduce(BigDecimal.ZERO, BigDecimal::add); if (debitSum.compareTo(creditSum) ! 0) { throw new BizException(借方金额与贷方金额不相等); } // 2. 生成凭证号日期 当日序号 String voucherNo generateVoucherNo(dto.getVoucherDate()); // 3. 保存主表 Voucher voucher new Voucher(); BeanUtils.copyProperties(dto, voucher); voucher.setVoucherNo(voucherNo); voucher.setStatus(0); this.save(voucher); // 4. 保存明细表 ListVoucherEntry entryList dto.getEntries().stream().map(item - { VoucherEntry entry new VoucherEntry(); BeanUtils.copyProperties(item, entry); entry.setVoucherId(voucher.getId()); return entry; }).collect(Collectors.toList()); voucherEntryMapper.insertBatch(entryList); return true; } }这里要注意Transactional注解必须加上而且rollbackFor要指定成Exception.class。Spring默认只在遇到RuntimeException时回滚如果你在Service里抛了一个自定义的BizException而它没有继承RuntimeException就会导致凭证主表插入成功、明细表插入失败数据就脏了。5.2 凭证编号并发问题加锁还是用数据库唯一约束凭证号有一个业务规矩一个月内凭证号从1开始连续编号不能跳号、不能重复。实现时有简单的做法和稳妥的做法。简单的做法是查一下表里当月凭证号最大的那条然后1。但这在并发场景下会发生两个请求同时查到同一个最大号生成同一张凭证号。毕设答辩一般不会真的拿并发去压测你但是老师可能会问你怎么处理并发。我的方案是双保险程序里用synchronized加JVM锁保证单实例下生成凭证号不冲突数据库里对voucher_no字段建唯一索引兜底。即使程序锁失效数据库也会抛出DuplicateKeyException不会真的插入重复数据。private synchronized String generateVoucherNo(Date date) { String prefix new SimpleDateFormat(yyyyMMdd).format(date); // 查询当天最大凭证号 Voucher latest voucherMapper.selectMaxNoByDate(prefix); int next latest null ? 1 : Integer.parseInt(latest.getVoucherNo().substring(9)) 1; return prefix - String.format(%04d, next); }我在实际写源码的时候很多毕设项目的做法是直接用UUID或者当前时间戳当凭证号这样确实不用操心并发但业务上完全说不过去——凭证号是会计凭证的关键标识无规则乱码编号会让审账的人抓狂。这一点你写到论文里也能体现你真的懂业务。5.3 过账逻辑从凭证到总账的汇总算法过账也叫记账是整个系统中最有会计感的操作。它把已审核的凭证分录按科目汇总到general_ledger表对应的期间行里。实现思路是这样的Transactional(rollbackFor Exception.class) public void postVouchers(ListLong voucherIds) { // 1. 锁定凭证置状态为过账 ListVoucher vouchers voucherMapper.selectBatchIds(voucherIds); vouchers.forEach(voucher - { if (voucher.getStatus() ! 1) { throw new BizException(存在非已审核状态的凭证无法过账); } // 2. 查询所有明细 ListVoucherEntry entries voucherEntryMapper.selectByVoucherId(voucher.getId()); for (VoucherEntry entry : entries) { // 3. 按科目和期间拿到或创建总账行 GeneralLedger gl generalLedgerMapper.selectBySubjectIdPeriod( entry.getSubjectId(), periodOf(voucher.getVoucherDate())); // 4. 借方发生额累加或贷方发生额累加 if (entry.getDirection() 1) { gl.setDebitTotal(gl.getDebitTotal().add(entry.getAmount())); } else { gl.setCreditTotal(gl.getCreditTotal().add(entry.getAmount())); } generalLedgerMapper.updateById(gl); } voucher.setStatus(2); voucherMapper.updateById(voucher); }); }这一步的难点不在代码量而在期间的处理一张凭证日期是5月28日那么它应该影响5月的总账而不能影响4月已经结账的数据。所以过账前需要判断凭证所属期间是否已经结账如果已结账必须禁止过账。这个判断逻辑要在过账方法的最前面做。5.4 报表查询科目余额表与利润表科目余额表是最能体现SQL功力的地方。它要把所有科目在某个期间内的期初余额、本期发生额、期末余额都查出来。我用MySQL的窗口函数CTE来实现MySQL 8.0以下做不到这么优雅WITH period_data AS ( SELECT subject_id, SUM(CASE WHEN direction 1 THEN amount ELSE 0 END) AS debit_total, SUM(CASE WHEN direction 2 THEN amount ELSE 0 END) AS credit_total FROM voucher_entry ve JOIN voucher v ON ve.voucher_id v.id WHERE DATE_FORMAT(v.voucher_date, %Y-%m) #{period} AND v.status IN (1, 2) GROUP BY subject_id ) SELECT s.subject_code, s.subject_name, s.balance_direction, COALESCE(gl.opening_balance, 0) AS opening_balance, COALESCE(pd.debit_total, 0) AS debit_total, COALESCE(pd.credit_total, 0) AS credit_total, CASE WHEN s.balance_direction 1 THEN COALESCE(gl.opening_balance, 0) COALESCE(pd.debit_total, 0) - COALESCE(pd.credit_total, 0) ELSE COALESCE(gl.opening_balance, 0) COALESCE(pd.credit_total, 0) - COALESCE(pd.debit_total, 0) END AS closing_balance FROM account_subject s LEFT JOIN general_ledger gl ON s.id gl.subject_id AND gl.period #{period} LEFT JOIN period_data pd ON s.id pd.subject_id ORDER BY s.subject_code;这段SQL的精华在CASE WHEN s.balance_direction 1那段——它根据科目的余额方向自动判断期末余额是借方加发生额还是贷方加发生额。如果不用这个字段你只能在前端写死判断科目编码前缀代码会很丑而且不灵活。利润表的逻辑其实就更简单了把损益类科目里收入相关的科目余额放在营业收入行成本费用类科目余额放在成本费用行最后用收入减成本费用得到净利润。难点在于不同行业的报表结构不同你在毕设里只需要做一个通用的、只包含一级损益科目的利润表即可不用纠结多级明细科目的归并。6. 毕设开发中最容易翻车的细节我踩过的坑你别再踩这一章专门聊聊我在实际参考和指导开发过程中见过的各种坑。每一个都真实存在每一个都可能导致你的毕设演示当场社死。6.1 金额用浮点型算着算着多出一分钱这是会计系统里最经典的低级错误。Java里float和double是二进制浮点数用它们做加减运算会产生精度丢失。经典案例double a 0.1; double b 0.2; System.out.println(a b); // 0.30000000000000004在凭证分录里有好几条金额每条金额还有多位小数用double累加后最终对账差个0.01排查起来痛不欲生。在会计行业一分钱对不上都是大事。所以所有金额字段一律使用BigDecimal数据库层面用DECIMAL(15,2)Java层面用BigDecimal。你可以在MyBatis Plus的实体类里给每个金额字段都加上类型处理器确保从数据库读出到Java对象都是BigDecimal。另外注意BigDecimal做加法时要用add方法并接收返回值不能直接改原对象的值。这个细节我在评审同学的代码时经常看到属于典型的看似会写其实没真正用过。6.2 期初余额不平衡报表就废了很多同学做系统时把期初数据通过SQL直接灌到数据库里根本不校验借贷平衡。等做到试算平衡表和资产负债表的查询输出时发现表怎么都对不上然后开始怀疑自己的SQL写错了。其实问题根源在期初数据就是不平的。解决方法是建一个期初余额导入/录入页面录入界面实时显示借方合计和贷方合计的差额。当差额不为零时禁止保存。这是一个很简单的功能但在答辩时很能体现你对会计业务的理解。6.3 后端校验形同虚设只靠前端我在一些毕设源码里看到过这样的现象Vue前端做了表单校验比如必填项检查、金额不能为负后端Controller完全信任前端传过来的参数直接保存。这样做在开发时确实顺滑但是一旦演示时有人直接调接口绕过前端传一个负数金额进来系统就乱了。正确的做法是后端必须做二次校验而且不能只校验非空还要校验业务规则。比如凭证明细至少要有两条每条分录必须有科目金额必须大于0等等。你的Service层应该第一步就是校验参数第二步才是业务逻辑这个顺序不要反。6.4 凭证改不了、删不掉历史数据乱成一团会计系统里凭证不允许物理删除只能作废。原因是审计要求留痕——凭证一旦被彻底删除财务数据的可追溯性就没了。所以在设计凭证模块时删除操作做的应该是逻辑删除把状态置为作废并且在凭证列表里依然能看到作废的凭证只是画面上有标识。这个设计在开发初期会让人感觉增加了不少麻烦删除变成改状态查列表要过滤状态但这是真实业务的要求。你如果做的是物理删除点一下直接没了答辩时老师大概率会追问你这样做符合会计规范吗答不上来就尴尬了。7. 源码之外论文写作和答辩演示的加分技巧最后这部分很多技术攻略不会写但对毕设来说非常实用——代码写得好不好是基础能讲清楚才是拿到高分的关键。7.1 论文的主体结构怎么排一般计算机毕设论文框架是绪论 / 相关技术 / 需求分析 / 系统设计 / 系统实现 / 系统测试 / 总结展望。会计信息管理系统的论文在系统设计一章里建议加入数据库逻辑结构设计把关键表的字段含义、表间关系讲清楚。在系统实现一章里不要流水账式地截图而是按照功能描述→核心代码→运行效果截图来组织每个模块挑一到两个真正有逻辑含量的代码片段来讲剩下的放在附录里就好。测试环节不要只写功能测试。凭证借贷平衡校验跨月过账限制权限越权访问拦截这三类测试用例要单独列出因为它们是针对系统特点设计的会让老师觉得你真的考虑了全面性。7.2 答辩演示的脚本化设计答辩现场最怕的是临场现找数据、现录凭证。正确的做法是提前准备好一套完整的演示数据把操作顺序写成脚本反复演练至少三遍。我推荐的演示顺序是登录系统先展示科目树和期初数据录一张简单的现金费用凭证展示借贷自动平衡的校验录一张包含辅助核算的销售凭证展示往来明细审核凭证过账查询总账和明细账展示凭证到账簿的数据流转生成科目余额表和利润表演示权限控制用会计账号登录看不到用户管理菜单整个流程控制在8到10分钟。关键的是第2步和第6步——前者展示你对业务规则的理解后者展示你的汇总查询能力。7.3 演示数据必须是干净且有说服力的不要在演示时用张三、李四、测试数据这种名字也不要录一堆金额相同的凭证。准备一套模拟的真实场景数据某公司5月份发生了销售、采购、费用报销、差旅借款、工资计提等业务每个业务都包含完整的分录合计金额能对上有寓意的数字。当老师问你这个利润表里的数字怎么来的你能指着一路从凭证说到总账再说报表整条链路无懈可击这个项目的可信度一下子就上来了。我个人在带学生的过程中体会到会计信息管理系统类毕业设计最关键的其实不是代码量有多大、界面有多炫而是业务逻辑是不是真的闭环了。你让一个没用过会计软件的人做这种系统会做出单纯的增删改查你让一个理解有借必有贷的人做做出来的就是有业务灵魂的工具。希望这篇文章能帮你把项目做成后者在毕业答辩和面试中都能挺直腰板讲出自己的设计。